Configuring and authenticating a health device

ABSTRACT

Deploying a mobile health device to provide a health service for a person for a health condition includes accessing a profile of the person, defining a value for a first parameter of the mobile health device based on the profile, configuring the mobile health device based on the value of the first parameter, and giving possession of the mobile health device to the person. Deploying a mobile health device to provide a health service for a person for a health condition may also include, after giving possession of the mobile health device, receiving a first communication from the mobile health device, in response to receiving the first communication, sending a second communication to a second device associated with the person, receiving a third communication, and authenticating that an operator in possession of the mobile health device is the person based on receipt of the third communication.

CROSS-REFERENCE TO RELATED APPLICATIONS

This application claims priority to U.S. provisional patent applicationNo. 62/858,759 filed on Jun. 7, 2019, titled “A NETWORK CONNECTEDMEDICAL MONITORING DEVICE WITH TEXT, AUDIO AND VIDEO COMMUNICATIONS,”and U.S. provisional patent application No. 62/865,411 filed on Jun. 24,2019, titled “A SYSTEM FOR SELECTING AND DELIVERING HEALTHINTERVENTIONS,” both of which are incorporated by reference herein.

TECHNICAL FIELD

This application is directed to the field of health services, and moreparticularly to remotely providing health services to a recipient usinga mobile device, including autonomously selecting and communicatinghealth information to a recipient as part of providing health servicesto the recipient, including, for example, specifying actions to perform.

BACKGROUND OF THE INVENTION

The Centers for Disease Control and Prevention estimate that six out often adults in the US have a chronic disease, while four out of ten havetwo or more chronic diseases. Two of the most widespread chronicconditions are hypertension and diabetes. According to recent reports bythe American Heart Association based on updated hypertension guidelines,almost half of US adults (46%) suffer from hypertension, and the overallnumber of people with high blood pressure exceeds 100 million. Accordingto such reports, the number of deaths caused by hypertension increasedby 38% through the period 2005-2015. On average, national medical costsassociated with hypertension have been estimated at about $131 billionin annual healthcare expenditure. According to some reports, over 30million Americans, or 9.4% of the population, have diabetes(approximately 1.25 million American children and adults have type 1diabetes); it is estimated that 7.2 million of those are undiagnosed.According to some reports, the percentage of Americans age 65 and olderwith diabetes remains high, at 25.2%, or 12.0 million seniors (diagnosedand undiagnosed), and diabetes remains the 7th leading cause of death inthe United States; in 2015, 79,535 death certificates listed it as theunderlying cause of death, and a total of 252,806 death certificateslisting diabetes as an underlying or contributing cause of death.According to some reports, total healthcare costs of diagnosed diabetesare at $327 billion, of which $237 billion are attributed to directmedical costs and $90 billion to reduced productivity. Diabetes isclosely related to hypertension: according to multiple studies, over 70%of diabetes patients have high blood pressure.

Chronic medical conditions like hypertension and diabetes requirefrequent (e.g., continuous) monitoring. There are multiple technologiesand medical monitoring devices on the market and in development formeasuring blood pressure and blood glucose levels. These products arecharacterized by a broad range of features, accuracy, usability,integration with other devices, connectivity, levels of support offeredto patients, price, insurance coverage, etc. Conventional blood pressuremonitors may use an upper arm cuff, but wrist monitors are also presenton the market. Top digital blood pressure monitors on the market mayoffer extensive memory, automatic averaging by multiple measurements,different types of displays and Bluetooth connectivity with asmartphone, which may receive, store and process blood pressure data andmay offer applications for advanced blood pressure analytics.

Glucometers measure blood glucose levels. There are two basic well-knowntypes of glucometers for diabetes patients: glucometers with separatetest strips for periodic testing of glucose levels by a patient andcontinuous glucose monitoring (CGM) devices, which typically have animplanted subcutaneous sensor, wireless transmitter and receiver, andautomatic measurement system, and which optionally may be combined withan insulin pump.

Most patients are capable of measuring their own blood pressure orglucose level with devices at home. In some cases, a patient may take aparticular action based on the measurements. For instance, a patient mayadminister themselves an insulin injection if their blood glucose levelis in a particular range. In extreme instances, a patient may contactmedical professionals if the home measurements are outside specificlimits. There are instances where the home measurements may indicate abenefit of a moderate correction/adjustment (e.g., a blood glucosemeasurement indicating that a patient should eat a piece of fruit), butmost patients, unless they have had significant training, are probablyunable to accurately determine if an adjustment/correction would beuseful or what the adjustment/correction would be. Although a patentobtaining periodic measurements at home could contact a medicalprofessional for guidance after each measurement, this is usually notpractical for a number of reasons, including cost.

Accordingly, it is desirable to provide a practical mechanism forproviding guidance to patients that measure their own blood pressure orglucose level with devices at home.

SUMMARY OF THE INVENTION

According to the system described herein, remotely providing a firsthealth service to a person for a health condition includes predefining aplurality of analysis types, each analysis type representing a type ofanalysis to be performed on information about the person to determine anintervention as part of providing a health service, predefining a firstrule specifying a condition under which to apply a first of theplurality of analysis types, performing the first health service on theperson, including detecting health values of one or more health metricsof the person associated with performance of the first health service,selecting the first analysis type to perform based on the first rule andinformation about the person, including the health values, performing afirst type of analysis on the information to determine whatinterventions to be undertaken based on the information as part ofperforming the first health service, and remotely communicating adetermined intervention to the person. A part of the first healthservice may be performed by a first health device locally coupled to theperson, remotely providing a first health service to a person for ahealth condition may further include the first health device detectingthe health values and transmitting the health values to a second deviceremotely located from the first health device, where the second deviceremotely communicates the determined intervention to the first healthdevice, and the first health device performs a first action based on theremote communication. The intervention may include altering a healthtreatment administered to the person as part of the first healthservice. Remotely providing a first health service to a person for ahealth condition may also include predefining a plurality ofcommunication types, including a notification, an instruction, aninquiry, feedback, a live conversation and an automated conversation,where performing the first type of analysis on the information includesdetermining a first communication type from among the plurality ofcommunication types for the communication, and where the intervention isremotely communicated as a communication of the first communicationtype. Remotely providing a first health service to a person for a healthcondition may also include predefining a plurality of media types,including text, audio, images and video, where performing the first typeof analysis on the information includes determining one or more of theplurality of media types with which to communicate with the person, andwhere the intervention is remotely communicated to the person using themedia types. The first analysis type may be autonomous analysis based onmachine learning and/or based on predefined rules.

According further to the system described herein, a system remotelyprovides a first health service to a person for a health condition basedon remotely detected values of health metrics of the person associatedwith performance of the first health service. The system includes one ormore processors and a memory having code stored thereon that, whenexecuted, predefines a plurality of analysis types, each analysis typerepresenting a type of analysis to be performed on information about theperson to determine an intervention as part of providing a healthservice, predefines a first rule specifying a condition under which toapply a first of the plurality of analysis types, selects the firstanalysis type to perform based on the first rule and on informationabout the person, including the one or more detected values, performs afirst type of analysis on the information to determine whatinterventions to be undertaken based on the information as part ofperforming the first health service, and remotely communicates adetermined intervention to the person. A part of the first healthservice may be performed by a first health device locally coupled to theperson and the first health device may detect the detected values andtransmit the one or more detected values to a second device remotelylocated from the first health device, the second device remotelycommunicating the determined intervention to the first health device,and the first health device performing a first action based on theremote communication. The determined intervention may include altering ahealth treatment administered to the person as part of the first healthservice. A plurality of communication types may be predefined to includea notification, an instruction, an inquiry, feedback, a liveconversation and an automated conversation and performing the first typeof analysis on the information may include determining a firstcommunication type from among the plurality of communication types forthe communication, the determined intervention being remotelycommunicated as a communication of the first communication type. Aplurality of media types may be predefined to include text, audio,images and video and performing the first type of analysis on theinformation may include determining one or more of the plurality ofmedia types with which to communicate with the person, the determinedintervention being remotely communicated to the person using the mediatypes. The first analysis type may be autonomous analysis based onmachine learning and/or on predefined rules.

According further to the system described herein, non-transitorycomputer-readable media has software stored thereon that remotelyprovides a health service to a person for a health condition based onremotely detected values of health metrics of the person associated withperformance of the health service. The software includes executable codethat defines a plurality of analysis types, each analysis typerepresenting a type of analysis to be performed on information about theperson to determine an intervention as part of providing the healthservice, executable code that defines a first rule specifying acondition under which to apply a first of the plurality of analysistypes, executable code that selects the first analysis type to performbased on the first rule and on information about the person, includingthe one or more detected values, executable code that performs a firsttype of analysis on the information to determine what interventions tobe undertaken based on the information as part of performing the firsthealth service, and executable code that remotely communicates adetermined intervention to the person. At least part of the first healthservice may be performed by a first health device locally coupled to theperson and the software may further include executable code thatcontrols the first health device to detect the values and transmits thevalues to a second device remotely located from the first health device,where the second device remotely communicates the determinedintervention to the first health device, and the first health deviceperforms an action based on the remote communication. The firstintervention may include altering a health treatment administered to theperson as part of the first health service. The software may furtherinclude executable code that predefines a plurality of communicationtypes, including a notification, an instruction, an inquiry, feedback, alive conversation and an automated conversation, where performing thefirst type of analysis on the information includes determining a firstcommunication type from among the plurality of communication types forthe communication, and where the determined intervention is remotelycommunicated as a communication of the first communication type. Thesoftware may further include executable code that predefines a pluralityof media types, including text, audio, images and video, whereperforming the first type of analysis on the information includesdetermining one or more of the plurality of media types with which tocommunicate with the person, and where the at least first interventionis remotely communicated to the person using the one or more mediatypes. The first analysis type may be autonomous analysis based at leastin part on machine learning.

According further to the system described herein, a mobile health deviceincludes a sensor that monitors values of a health metric of a person, acontrol component that controls the mobile health device to performactions as part of providing a health service, where the controlcomponent includes an input that receives audio signals corresponding tothe monitored values of the health metric, and produces a control signalbased on information about the person, including the monitored values ofthe health metric of the person, and components of the mobile healthdevice that receive the control signal and perform an action to providethe health service based on the control signal, where the componentsinclude user output components for producing sound and/or displayinginformation and where providing the health service includes playinginformation as sound, displaying information as text, displayinginformation as motion video, and/or displaying information still images.The mobile health device may also include a network interface componentthat communicates with a remote device that is remotely coupled to themobile health device as part of providing the health service. Thenetwork interface component may communicate the monitored values to theremote device, which has an audio capture device that captures voicesignals corresponding to the monitored values of the health metric. Thenetwork interface component may receive communications from the remotedevice that include encoded audio information corresponding to theprovided health service and the mobile health device may further includean audio player that produces decoded audio signals from the encodedaudio information and a speaker that produces sound from the decodedaudio signals. The encoded audio information may include encoded voicesignals of a health practitioner. The mobile health device may alsoinclude an audio capture device that captures voice signals of theperson, an audio encoding component that encodes the captured voicesignals, and telephony logic communicatively coupled to the networkinterface component, the audio encoding component and the audio playerthat controls the exchange of real-time voice communications between thehealth professional and the person. The mobile health device may alsoinclude an audio capture device that captures voice signalscorresponding to the monitored values of the health metric from whichthe audio input signals are produced. The mobile health device may alsoinclude a speech-to-text conversion module that converts voice signalsto text associated with the health service, where the network interfacecomponent transmits information corresponding to the monitored values ofthe health metric based on the text. The health metric may be a bloodpressure level and/or blood glucose level. The control component mayconvert each received audio signal to an input value and determine thecontrol signal based on the input value.

According further to the system described herein, for a mobile healthdevice including a sensor that monitors values of a health metric of aperson, a control component that controls the mobile health device toperform actions as part of providing a first health service, where thecontrol component includes an input that receives audio signalscorresponding to the monitored values of the health metric, and producesa control signal to control components of the mobile health device, andcomponents that receive the control signal and perform an action basedon the control signal as part of providing the health service, where thecomponents include user output components that produce sound and/ordisplay information, operating the mobile health device includesdetermining which of the following output actions to perform inproviding the health service based on information about the person,including the monitored values of the health metric of the person,playing information as sound on the user output components, displayinginformation as text on the user output components, displayinginformation as motion video on the user output components, anddisplaying information as still images on the user output components,and the control component controlling the user output components toperform a determined user output action. A network interface componentmay exchange communications with a remote device that is remotelycoupled to the mobile health device as part of providing the healthservice, where the network interface component receives communicationsfrom the remote device. The network interface component may communicatethe monitored values to the remote device, the remote device includingan audio capture device that captures voice signals corresponding to themonitored values of the health metric from which the audio input signalsare produced. The network interface component may receive communicationsfrom the remote device that include encoded audio informationcorresponding to the provided health service, where the mobile healthdevice may further include an audio player that produces decoded audiosignals from the encoded audio information and may include a speakerthat produces sound from the decoded audio signals. The encoded audioinformation may include encoded voice signals of a health practitioner.Determining output actions to perform may further include capturingvoice signals of the person, encoding the captured voice signals, andexchanging real-time voice communications between the healthpractitioner and the person. Determining output actions to perform mayfurther include capturing voice signals corresponding to monitoredvalues of the health metric from which the first audio input signals areproduced. Determining output actions to perform may further includeconverting voice signals to text associated with the provided firsthealth service corresponding to the detected health metric andtransmitting information corresponding to the monitored values of thehealth metric based on the text. The health metric may be a bloodpressure level and/or blood glucose level.

According further to the system described herein, for a mobile healthdevice including a sensor that monitors values of a health metric of aperson, a control component that controls the mobile health device toperform one or more actions as part of providing a health service, wherethe control component includes an input that receives first audiosignals corresponding to monitored values of the health metric, andproduces a control signal to control components of the mobile healthdevice, and components that receive the control signal and perform anaction based on the control signal as part of providing the healthservice, where the components include user output components forproducing sound and/or displaying information, non-transitorycomputer-readable media having software stored thereon includesexecutable code that determines which one or more of the followingoutput actions to perform to provide the health service based oninformation about the person, including the monitored values of thehealth metric of the person, playing information as sound on the useroutput components, displaying information as text on the user outputcomponents, displaying information as motion video on the user outputcomponents, and displaying information as still images on the useroutput components, and executable code within the control component thatcontrols the user output components to perform the determined useroutput actions.

According further to the system described herein, deploying a mobilehealth device to provide a health service for a person for a healthcondition includes accessing a profile of the person, defining a valuefor a first parameter of the mobile health device based on the profile,configuring the mobile health device based on the value of the firstparameter, and giving possession of the mobile health device to theperson. Deploying a mobile health device to provide a health service fora person for a health condition may also include, after givingpossession of the mobile health device, receiving a first communicationfrom the mobile health device, in response to receiving the firstcommunication, sending a second communication to a second deviceassociated with the person, receiving a third communication, andauthenticating that an operator in possession of the mobile healthdevice is the person based on receipt of the third communication. Thesecond communication may include an access code, where the thirdcommunication is from the mobile health device and includes the accesscode, and where authenticating is based on the third communicationincluding the access code. The third communication may be from thesecond device, and authenticating may be based on the thirdcommunication being received from the second device. Deploying a mobilehealth device to provide a health service for a person for a healthcondition may also include creating the profile for the person at a timeof purchase or order of the mobile health device. The profile mayinclude a first parameter value specific to the person and associatedwith a health condition of the person. The mobile health device mayinclude a health sensor for monitoring a value of a health metric of theperson the first parameter value may be specific to the health sensor.

According further to the system described herein, a system for deployinga mobile health device to provide a health service for a person having ahealth condition includes one or more processors and a memory havingcode stored thereon that, when executed, accesses a profile of theperson, defines a value for a first parameter of the mobile healthdevice based on the profile, and configures the mobile health devicebased on the value of the first parameter. The code, when executed, mayreceive a first communication from the mobile health device after theperson takes possession of the mobile health device, send a secondcommunication to a second device associated with the person in responseto receiving the first communication, receive a third communication,and, based on receipt of the third communication, authenticate that anoperator in possession of the mobile health device is the person. Thesecond communication may include an access code, the third communicationmay be from the mobile health device and may include the access code,and the authenticating may be based on the third communication includingthe access code. The third communication may be from the second device,and authenticating may be based on the third communication beingreceived from the second device. The code, when executed, may create theprofile for the person at a time of purchase or order of the mobilehealth device. The profile may include a first parameter value specificto the person and associated with the health condition of the person.The mobile health device may include a health sensor for monitoring avalue of a health metric of the person, and the first parameter valuemay be specific to the health sensor.

According further to the system described herein, non-transitorycomputer-readable media has software stored thereon that deploys amobile health device to provide a health service for a person with ahealth condition. The software includes executable code that accesses aprofile of the person, executable code that defines a value for a firstparameter of the mobile health device based on the profile, andexecutable code that, prior to possession of the mobile health devicebeing given to the person, configures the mobile health device based onthe value of the first parameter. The software may also includeexecutable code that, after possession of the mobile health device hasbeen given to the person, receives a first communication from the mobilehealth device, executable code that, in response to receiving the firstcommunication, sends a second communication to a second deviceassociated with the person, executable code that receives a thirdcommunication, and executable code that authenticates that an operatorin possession of the mobile health device is the person based on receiptof the third communication. The second communication may include anaccess code, the third communication may be from the mobile healthdevice and include the access code, and authenticating may be based onthe third communication including the access code. The thirdcommunication may be from the second device, and the authenticating maybe based on the third communication being received from the seconddevice. The software may also include executable code that creates theprofile for the person at a time of purchase or order of the mobilehealth device. The mobile health device may include a health sensor formonitoring a value of a health metric of the person, and the profile mayinclude a first parameter value specific to the health sensor.

According further to the system described herein, for a system includinga mobile health device locally coupled to a person and a remote deviceremotely coupled to the mobile health device, remotely providing ahealth service to a person for a health condition includes the remotedevice determining a health condition for which the health service isbeing provided, the remote device sending a first communication to themobile health device requesting that the mobile health device capturevisual information associated with the health condition, the mobilehealth device capturing the visual information associated with thehealth condition, and the mobile health device transmitting the visualinformation to the remote device. The mobile health device may include ahealth sensor for monitoring values of a health metric and remotelyproviding a health service to a person for a health condition may alsoinclude the mobile health device detecting values of the health metricand transmitting a second communication from the mobile health device tothe remote device, where determining the health condition and sendingthe first communication may be performed by the remote device inresponse to receiving the second communication. Prior to capturing thevisual information, remotely providing a health service to a person fora health condition may also include detecting one or more images,applying image recognition techniques to determine whether the one ormore images satisfy the visual information requested, and, if the one ormore images satisfy the visual information requested, instructing a userof the health device to capture the visual information. Remotelyproviding a health service to a person for a health condition may alsoinclude, after capturing the visual information, applying imagerecognition techniques to images of the captured visual information todetermine whether the images satisfy the visual information requested,and, if the images do not satisfy the visual information requested,indicating to a user that the images do not satisfy the visualinformation requested. The visual information may be video and/or astill image. The first communication may include instructions forcapturing the visual information. The instructions may be provided tothe person to use the mobile health device to capture the visualinformation.

According further to the system described herein, a system for remotelyproviding a health service to a person for a health condition includes amobile health device locally coupled to the person and a remote deviceremotely coupled to the mobile device and having one or more processorsand a memory with code stored thereon that, when executed, determinesthe health condition for which the health service are being provided,and sends a first communication to the mobile health device requestingthat the mobile health device capture visual information associated withthe health condition, where the mobile health device includes one ormore processors and a memory having code stored thereon that controlsthe mobile health device to capture the visual information associatedwith the health condition and transmit the visual information to theremote device. The mobile health device may detect values of a healthmetric and transmit a second communication to the remote device, anddetermining the health condition and sending the first communication maybe performed by the remote device in response to receiving the secondcommunication. Prior to capturing the visual information, the mobilehealth device may detect images, apply image recognition techniques todetermine whether the images satisfy the visual information requestedand, if the images satisfy the visual information requested, instruct auser of the health device to capture the visual information. Aftercapturing the visual information, image recognition techniques may beapplied to images of the captured visual information to determinewhether the images satisfy the visual information requested, and, if theimages do not satisfy the visual information requested, the mobilehealth device may indicate to a user that the images do not satisfy thevisual information requested. The visual information may be a stillimage. The first communication may include instructions for the personto capture the visual information. The person may control the mobilehealth device to capture the visual information in accordance with theinstructions.

According further to the system described herein, for a system includinga mobile health device locally coupled to a person and to a remotedevice remotely coupled to the mobile health device, non-transitorycomputer-readable media has software stored thereon for providing ahealth service to the person for a health condition. The softwareincludes executable code that controls the remote device to determinethe health condition for which the health service is being provided, andsend a first communication to the mobile health device requesting thatthe mobile health device capture visual information associated with thehealth condition and executable code that controls the mobile healthdevice to capture the visual information associated with the healthcondition and transmit the visual information to the remote device. Themobile health device may include a health sensor for monitoring valuesof a health metric and the software may further include executable codethat controls the mobile health device to detect values of the healthmetric and transmit a second communication from the mobile health deviceto the remote device, where determining the health condition and sendingthe first communication may be performed by the remote device inresponse to receiving the second communication. Images may be detectedprior to capturing the visual information and the software may furtherinclude executable code that applies image recognition techniques todetermine whether the images satisfy the visual information requestedand executable code that, if the images satisfy the visual informationrequested, indicates to a user of the health device to capture thevisual information. The software may further include executable codethat, after the visual information is captured, applies imagerecognition techniques to images of the captured visual information todetermine whether the images satisfy the visual information requestedand executable code that, if the images do not satisfy the visualinformation requested, indicates to a user that the images do notsatisfy the visual information requested. The first communication mayinclude instructions for the person for capturing the visualinformation, and the person may control the mobile health device tocapture the visual information in accordance with the instructions.

According further to the system described herein, a mobile health devicefor providing a health service for a person includes a health sensorthat monitors values of a health metric of the person, a power controlcomponent that controls supplying power to the health sensor and toother components of the mobile health device, and a motion sensor,coupled to the power control component, that detects a motion of themobile health device, where the motion sensor sends a communication tothe power control component in response to detection of the motion toactivate the other components of the mobile health device. Thecommunication may specify a duration of the motion, and the powercontrol component may activate at least one of the other components ofthe mobile health device based on the duration. The communication mayspecify a direction of the motion, and the power control component mayactivate at least one of the other components of the mobile healthdevice based on the direction. The other components may include anetwork interface component that communicates with a remotely coupleddevice to provide the health service to the person. The communicationmay be generated based on a comparison between the motion and a motionprofile indicative of motion patterns associated with the health device.The mobile health device may be a hand-held device. The health sensormay have a physical interconnect for connecting with a health accessoryemployed by the health sensor to monitor values of health metrics, andthe communication may be generated based on detection of the healthaccessory becoming connected to the physical interconnect.

According further to the system described herein, for a mobile healthdevice including a health sensor that monitors values of health metricsof a person, and a power control component that controls supplying powerto the health sensor and to other components of the mobile healthdevice, providing a health service for the person includes detectingmotion of the mobile health device, sending a communication to the powercontrol component corresponding to detection of the motion, and thepower control component activating at least one of the other componentsof the mobile health device based on a communication. The communicationmay specify a duration of the motion, and the power control componentmay activate the at least one of the other components based on theduration. The communication may specify a direction of the motion, andthe power control component may activate the at least one of the othercomponents based on the direction. The at least one of the othercomponents may include a network interface component that communicateswith a remotely coupled device to provide the health service to theperson. The health device may have a motion profile indicative of motionpatterns associated with the health device and providing a healthservice for the person may include comparing the motion to the motionprofile and generating the communication based on the comparison. Themobile health device may be a hand-held device. The health sensor mayhave a physical interconnect for connecting with a health accessoryemployed by the health sensor to monitor the values of the health metricand providing a health service for the person may include detecting whenthe health accessory becomes connected to the physical interconnect,where the communication may be generated based on detection of thehealth accessory becoming connected to the physical interconnect.

According further to the system described herein, for a mobile healthdevice including a health sensor that monitors values of health metricsof a person, and a power control component that controls supplying powerto the health sensor and to other components of the mobile healthdevice, non-transitory computer-readable media has software storedthereon that provides a health service for a person. The softwareincludes executable code that detects a motion of the mobile healthdevice, executable code that sends a communication to the power controlcomponent corresponding to detection of the motion, and executable codethat controls the power control component to activate at least one ofthe other components of the mobile health device based on thecommunication. The communication may specify a duration of the motion,and the power control component may activate the at least one of theother components of the mobile health device based on the duration. Thecommunication may specify a direction of the motion, and the powercontrol component may activate the at least one of the components of themobile health device based on the direction. At least one of thecomponents may include a network interface component that communicateswith a remotely coupled device to provide the health service to theperson. The health device may have a motion profile indicative of motionpatterns associated with the health device and the software may furtherinclude executable code that compares the motion to the motion profileand executable code that generates the communication based on thecomparison. The health sensor may have a physical interconnect forconnecting with a health accessory employed by the health sensor tomonitor the values of the health metric and the software may furtherinclude executable code that detects when the health accessory becomesconnected to the physical interconnect, and executable code thatgenerates the communication based on detection of the health accessorybecoming connected to the physical interconnect.

According further to the system described herein, a mobile health devicefor providing a health service for a person includes a health sensorthat monitors values of health metrics of the person, where performanceof the health sensor is affected by temperature, an internal temperaturesensor that monitor a temperature of an internal region of the mobilehealth device, and a thermal control component that controls a thermaloutput of one or more components of the mobile health device based atleast in part on the temperature of the one or more internal regions ofthe health sensor. The mobile health device may also include a pluralityof processing cores that execute instructions where the thermal controlcomponent reduces a collective thermal output of the plurality ofprocessing cores by reducing a number of the plurality of the processingcores that actively execute instructions. The mobile health device mayalso include a processing core that executes instructions, where thethermal control component reduces a thermal output of the processingcore by reducing a frequency of instruction execution of the processingcore. The mobile health device may also include an external temperaturesensor that monitors a temperature of an external region that isexternal to the mobile health device and compensation logic thatdetermines a difference between a monitored internal temperature valueand a monitored external temperature value, and modifies monitoredhealth metric values based on a determined difference. The mobile healthdevice may also include a thermal buffer between the health sensor andan other component of the mobile health device that generate heat duringoperation of the mobile health device, the thermal buffer being arrangedto thermally insulate the health sensor from the other component.

According further to the system described herein, for a mobile healthdevice including a health sensor, a temperature sensor and a thermalcontrol component, providing a health service for a person includes thehealth sensor monitoring values of health metrics of the person, whereperformance of the health sensor is affected by temperature, theinternal temperature sensor monitoring a temperature of an internalregion of the mobile health device, and a thermal control componentcontrolling a thermal output of components of the mobile health devicebased on the monitored temperature of the internal region of the healthsensor. The mobile health device may further include a plurality ofprocessing cores that execute instructions and providing a healthservice for a person may also include the thermal control componentreducing a collective thermal output of the plurality of processingcores by reducing a number of the plurality of the processing cores thatactively execute instructions. The mobile health device may furtherinclude a processing core that executes instructions and providing ahealth service for a person may also include the thermal controlcomponent reducing a thermal output of the processing core by reducing afrequency of instruction execution of the processing core. The mobilehealth device further includes an external temperature sensor andproviding a health service for a person may also include the externaltemperature sensor monitoring a temperature of an external region thatis external to the mobile health device, determining a differencebetween a monitored internal temperature value and a monitored externaltemperature value, and modifying one or more monitored health metricvalues based at least in part on the determined difference. The mobilehealth device may include a thermal buffer between the health sensor andan other component that generates heat during operation of the mobilehealth device and the thermal buffer may be arranged to thermallyinsulate the health sensor from the other component.

According further to the system described herein, for a mobile healthdevice including a health sensor, a temperature sensor and a thermalcontrol component, non-transitory computer-readable media has softwarestored thereon that provides a health service for a person. The softwareincludes executable code that controls the health sensor to monitorvalues of health metrics of the person, where performance of the healthsensor is affected by temperature, executable code that controls theinternal temperature sensors to obtain a temperature for an internalregion of the mobile health device, and executable code that controls athermal control component to control a thermal output of components ofthe mobile health device based on the monitored temperature of theinternal region of the health sensor. The mobile health device mayfurther include a plurality of processing cores that executeinstructions and the software may further include executable code thatcontrols the thermal control component to reduce a collective thermaloutput of the plurality of processing cores by reducing a number of theplurality of the processing cores that actively execute instructions.The mobile health device may further include a processing core thatexecutes instructions and the software may further include executablecode that controls the thermal control component to reduce a thermaloutput of the processing core by reducing a frequency of instructionexecution of the processing core. The mobile health device may furtherinclude an external temperature sensor and the software may furtherexecutable code that, for an external region that is external to themobile health device, controls the external temperature sensor tomonitor a temperature of the external region, executable code thatdetermines a difference between a monitored internal temperature valueand a monitored external temperature value, and executable code thatmodifies monitored health metric values based on the determineddifference. The mobile health device may include a thermal bufferbetween the health sensor and an other component that generates heatduring operation of the mobile health device and the thermal buffer maybe arranged to thermally insulate the health sensor from the othercomponent.

According further to the system described herein, providing to a persona health service for a health condition includes receiving, from ahealth sensor of a mobile health device over an initial period, aplurality of initial values of health metrics of the person associatedwith performance of the health service, determining, based on theinitial values, baseline values of the health metrics for the person,receiving, from the health sensor at a time after the initial period, anadditional value corresponding to at least one of the health metrics,and determining whether the additional value represents an irregularitywith respect to the baseline values for the person. Providing to aperson a health service for a health condition may also include, if itis determined that the additional value represents an irregularity withrespect to the baseline values, communicating the irregularity to aprovider of the health service. Providing to a person a health servicefor a health condition may also include, if it is determined that theadditional value represent an irregularity with respect to the baselinevalues, communicating the irregularity to an operator of the mobilehealth device. Providing to a person a health service for a healthcondition may also include receiving input from the operator through auser interface of the mobile health device to address the irregularity.Providing to a person a health service for a health condition may alsoinclude the mobile health device communicating the initial values andthe additional value to a remote device remotely coupled to the mobilehealth device and the remote device determining the baseline values anddetermining whether the additional value represents an irregularity withrespect to the baseline values. Providing to a person a health servicefor a health condition may also include, if the remote device determinesthat the additional value represent an irregularity with respect to thebaseline values, the remote device communicating the irregularity to anoperator of the mobile health device, where the mobile health devicereceiving the additional value, determining whether the additional valuerepresents an irregularity, and communicating the irregularity areperformed in real-time. Determining baseline values of the health anddetermining whether the additional value represents an irregularity maybe performed by the mobile health device.

According further to the system described herein, a system for providinga health service to a person for a health condition includes one or moreprocessors and a memory having code stored thereon that, when executed,receives, from a health sensor of a mobile health device over an initialperiod, a plurality of initial values of health metrics of the personassociated with performance of the health service, determines, based onthe initial values, baseline values of the health metrics for theperson, receives, from the health sensor at a time after the initialperiod, an additional value corresponding to at least one of the healthmetrics, and determines whether the additional value represent anirregularity with respect to the baseline values for the person. If itis determined that the additional value represents an irregularity withrespect to the baseline values, the irregularity may be communicated toa provider of the health service. If it is determined that theadditional value represents an irregularity with respect to the baselinevalues, the irregularity may be communicated to an operator of themobile health device. Input from the operator may be received through auser interface of the mobile health device to address the irregularity.The mobile health device may communicate the initial values and theadditional value to a remote device remotely coupled to the mobilehealth device and the remote device may determine the baseline valuesand determine whether additional value represent an irregularity withrespect to the baseline values. If the remote device determines that theadditional value represent an irregularity with respect to the baselinevalues, the remote device may communicate the irregularity to anoperator of the mobile health device. Receiving the additional value,determining whether the additional value represent an irregularity, andcommunicating the irregularity may all be performed in real-time.

According further to the system described herein, non-transitorycomputer-readable media has software stored thereon for providing aperson with a health service for a health condition. The softwareincludes executable code that receives, from a health sensor of a mobilehealth device over an initial period, a plurality of initial values ofhealth metrics of the person associated with performance of the healthservice, executable code that determines, based on the initial values,baseline values of the health metrics for the person, executable codethat receives, from the health sensor at a time after the initialperiod, an additional value corresponding to at least one of the healthmetrics, and executable code that determines whether the additionalvalue represents an irregularity with respect to baseline values for theperson. The software may further include executable code that, if it isdetermined that the additional value represents an irregularity withrespect to the baseline values, communicates the irregularity to aprovider of the health service. The software may further includeexecutable code that, if it is determined that the additional valuerepresents an irregularity with respect to the baseline values,communicates the irregularity to an operator of the mobile healthdevice. The software may further include executable code that receivesinput from the operator through a user interface of the mobile healthdevice to address the irregularity. The software may further includeexecutable code that controls the mobile health device to communicatethe initial values and the additional value to a remote device coupledto the mobile health device and executable code that controls the remotedevice to determine the initial values and to determine whether theadditional value represent an irregularity with respect to the baselinevalues. The software may further include executable code that, if theremote device determines that the additional value represents anirregularity with respect to the baseline values, controls the remotedevice to communicate the irregularity to an operator of the mobilehealth device, where receiving the values, determining whether theadditional values represent an irregularity, and communicating theirregularity are performed in real-time.

According further to the system described herein, remotely providing ahealth service to a person for a health condition includes receiving ata device, in real time, values of a health metric detected by a healthdevice locally coupled to the person and remotely coupled to the device,applying automated machine learning in real-time to the values and tohistorical information specific to the person, including informationcorresponding to the health condition, to determine an intervention aspart of providing the health service, the intervention includingperformance of a determined action, and sending a communication from thedevice to the health device directing performance of the determinedaction. Remotely providing a health service to a person for a healthcondition may also include determining a time at which to perform thedetermined action, where the communication indicates the time at whichto perform the determined action. Remotely providing a health service toa person for a health condition may also include determining whether anexpiration time for the determined action has been reached andpreventing or halting the determined action based on determining thatthe expiration time has been reached. Remotely providing a healthservice to a person for a health condition may also include generating apreliminary list of actions based on the values and on the historicalinformation, comparing the preliminary list to a list of safe actions,and removing from the preliminary list any action that is not on thelist of safe actions to produce a safe list of actions that includes thedetermined action. Remotely providing a health service to a person for ahealth condition may also include generating a preliminary list ofactions based on the values and on the historical information,determining a best action from the preliminary list, and sending acommunication from the device to the health device directing performanceof the best action.

According further to the system described herein, a system for remotelyproviding a health service to a person for a health condition includesone or more processors and a memory having code stored thereon that,when executed, receives at a device, in real time, values of a healthmetric detected by a health device locally coupled to the person andremotely coupled to the device, applies automated machine learning inreal-time to the values and to historical information specific to theperson, including information corresponding to the health condition, todetermine an intervention as part of providing the first health service,the intervention including performance of a determined action, and sendsa communication from the device to the health device directingperformance of the determined action. The communication may indicate atime at which to perform the determined action. The code may determinewhether an expiration time for the determined action has been reachedand may prevent or halt the determined action based on the determinationthat the expiration time has been reached. The code may generate apreliminary list of actions based on the values and the historicalinformation, compare the preliminary list to a list of safe actions, andremove from the preliminary list any action that is not on the list ofsafe actions to produce a safe list of actions that includes thedetermined action. The code may generate a preliminary list of actionsbased on the values and the historical information, determine at leastone best action from the preliminary list, and send a communication fromthe device to the health device directing performance of the bestaction.

According further to the system described herein, non-transitorycomputer-readable media has software stored thereon for remotelyproviding a health service to a person for a health condition. Thesoftware includes executable code that receives at a device, in realtime, values of a health metric detected by a health device locallycoupled to the person and remotely coupled to the device, executablecode that applies automated machine learning in real-time to the valuesand to historical information specific to the person, includinginformation corresponding to the health condition, to determine anintervention as part of providing the first health service, theintervention including performance of a determined action, andexecutable code that sends a communication from the device to the healthdevice directing performance of the determined action. The software mayfurther include executable code that determines a time at which toperform the determined action, where the communication indicates thetime at which to perform the determined action. The software may furtherinclude executable code that determines whether an expiration time forthe determined action has been reached and executable code that preventsor halts the determined action based on the determination that theexpiration time has been reached. The software may further includeexecutable code that generates a preliminary list of actions based onthe values and on the historical information, executable code thatcompares the preliminary list to a list of safe actions, and executablecode that removes from the preliminary list any action that is not onthe list of safe actions to produce a safe list of actions that includesthe determined action. The software may further include executable codethat generates a preliminary list of actions based on the values and thehistorical information, executable code that determines a best actionfrom the preliminary list, and executable code that sends acommunication from the device to the health device directing performanceof the best action.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram illustrating a system for remotely providing ahealth service to a recipient, according to embodiments of the systemdescribed herein.

FIG. 2A is a block diagram illustrating a schematic representation of amobile health device, according to embodiments of the system describedherein.

FIG. 2B is a plan view of a mobile health device, according toembodiments of the system described herein.

FIG. 2C is a perspective view of a mobile health device mounted on abase station for the health device, according to embodiments of thesystem described herein.

FIG. 2D is a block diagram illustrating an example of a controller of ahealth device, according to embodiments of the system described herein.

FIG. 3A is a data flow diagram illustrating a system for remotelyproviding a health service to a recipient, according to embodiments ofthe system described herein.

FIG. 3B is a block diagram illustrating at least a portion of a healthdata model, according to embodiments of the system described herein.

FIG. 4 is a diagram illustrating health communication characteristics,according to embodiments of the system described herein.

FIG. 5 is a flowchart illustrating remotely providing a health serviceto a recipient, according to embodiments of the system described herein.

FIG. 6 is a flowchart illustrating constructing a health data model,according to embodiments of the system described herein.

FIG. 7 is a flowchart illustrating preconfiguring an MLE, according toembodiments of the system described herein.

FIG. 8 is a flowchart illustrating configuring a mobile health deviceprior to delivering possession to a recipient, according to embodimentsof the system described herein.

FIG. 9 is a flowchart illustrating authenticating a user of a mobilehealth device, according to embodiments of the system described herein.

FIG. 10 is a flowchart illustrating activating a mobile health device inresponse to detecting motion of the mobile health device, according toembodiments of the system described herein.

FIG. 11 is a flowchart illustrating reducing power consumption of amobile health device based on detected temperature, according toembodiments of the system described herein.

FIG. 12 is a flowchart illustrating applying an MLE to determine one ormore interventions as part of providing a health service, according toembodiments of the system described herein.

FIG. 13 is a flowchart illustrating filtering a list of one or moredetermined actions against a list of safe actions, according toembodiments of the system described herein.

FIG. 14 is a flowchart illustrating detecting irregularities of healthmetric values, and taking action based on this detection, according toembodiments of the system described herein.

DETAILED DESCRIPTION OF VARIOUS EMBODIMENTS

Traditional healthcare delivery is conducted through direct interactionswith clinicians or other health care providers who analyze medicalinformation of a patient, including historical information and currentlydetected information, and then, based on the analysis, performprocedures or prescribe other interventions such as medication andtherapy. For acute problems like broken bones, this model of deliverycan be efficient and effective. For long-term chronic medicalconditions, direct interactions with medical specialists may be toocostly and/or infrequent to adequately monitor and or treat such chronicconditions. Such chronic conditions may require more frequent monitoringand adjustments of treatment outside a physician's office hours.

More frequent monitoring (e.g., continuous monitoring) may be achievedby a patient or personal caregiver, independently from a trainedpractitioner, using a mobile device (e.g., including a medical sensorand/or other medical functionality) locally coupled to the patientand/or operated by the patient or the personal caregiver. For example, aCGM may be employed to continuously monitor blood glucose levels in apatient. A device (e.g., a mobile device with medical or other healthfunctionality) may be deemed locally coupled to a person (e.g., apatient) if: the device itself, a portion thereof, or an accessoryphysically attached thereto (e.g., wire, a tube, a syringe, a catheter,a blood pressure cuff, blood pressure wrist monitor, other type of wristmonitor, patch, etc.) is in physical contact with the person's skin, isnear enough to the person's body to detect a measurable value of ahealth metric (e.g., a physical property) of the person, is currentlyinserted in the patient's body, or resides within the person's body;and/or if the device is in direct wireless communication with anelectromagnetic device (e.g., medical sensor) within the person's body,for example, a subcutaneous sensor of a CGM or pacemaker.

However, notwithstanding significant progress in the development ofmedical devices for monitoring health metrics, e.g., for outpatientservices, such medical devices may lack the capability to wirelesslyconnect to a cloud service, much less a cloud service that providesreal-time analysis of the patient's condition based at least in part onthe detected values of remotely monitored health metrics.

Accordingly, it may be desirable to provide medical services thataddress these potential shortcomings.

Described herein are a system and techniques for providing remote healthservices (e.g., medical services) to a recipient of the health services(e.g., a patient). In some embodiments, the system described herein mayinclude a network-connected mobile device (e.g., with health monitoringfunctionality; e.g., medical sensors) and cloud services configured forreliable data exchange and remote monitoring and analysis of arecipient's health metrics (e.g., blood pressure, blood glucose level,pulse and other metrics), which may enable providing health servicesremotely and in real time. Such remote health services may includedetermining a customized treatment for a recipient, for example, basedon the recipient's profile and health history (including, e.g., medicalhistory), including remotely monitored health metrics of the recipient.

The customized treatment may be determined by a trained practitioner,who analyzes a recipient profile and health history, including, forexample, monitored health metrics, pharmaceutical usage, socio-economicfactors and recipient feedback. The practitioner may analyze andreconcile information from these disparate sources and choose one ormore interventions to recommend. These interventions may include, forexample, direct medical or therapeutical procedures, other directactions or adjustments to a recipient's care regimen or lifestyle thatthe recipient and/or a caregiver implements. Later, the practitioner mayanalyze the effects of those interventions, by again analyzing therecipient profile and health history, which now may include healthmetric measurements and recipient feedback occurring after thepreviously recommended interventions were performed. The practitioner'sanalysis may result in the practitioner adjusting the recommendedinterventions accordingly. This process may be performed iterativelyover time.

This process including aggregation of recipient information,interpretation, intervention, and adjustment described above, performediteratively, may be effective in treating the recipient, but it may notbe cost effective to perform more than a few times per year. That is,the cost associated with employing the time and expertise of the trainedpractitioner to perform such a process more than a few times a year maybe cost prohibitive to a recipient. Furthermore, depending on apractitioner's caseload, it may not be feasible for the practitioner toperform such a process more than just a few times per year while keepingup with the practitioner's caseload. Also, given the caseload of apractitioner, and practical time constraints, it may prove difficult forthe practitioner to effectively digest all of the information availablefor aggregation and interpretation to determine and adjust interventionsfor the recipient.

Thus, it may be desirable to provide real-time remote health services(e.g., for a health condition for which one or more health metrics areremotely—and perhaps continuously—monitored), for example, in a mannerthat is reliable, time-efficient and cost-effective for recipientsand/or practitioners.

The system and techniques described herein may provide remote healthservices, for example, in real time, based on values of health metricsmonitored remotely, and in some embodiments, continuously, for arecipient. The system may include a mobile health device, for example, amobile medical device (e.g., a glucometer), configured to continuallymonitor or intermittently detect values of one or more health metrics. Amobile health device may be configured for handheld operation and/ortable-top operation, may be locally coupled to a recipient, and mayinclude a health sensor (e.g., a medical sensor) that detects (e.g.,monitors) values of one or more health metrics of the recipient,detecting such values continuously or intermittently (e.g., periodicallyor in response to user input). While embodiments of the system describedherein are illustrated using a single health sensor, it should beappreciated that the invention is not so limited, as a health device mayinclude multiple health sensors, and each health sensor may detectvalues for one or more health metrics.

The system described herein may include one or more servers remotelycoupled to the mobile health device (e.g., over one or morecommunications networks) that are in communication with the healthdevice and provide one or more health services (e.g., cloud services orcloud-based services) based at least in part on health metric valuesdetected by the health device and transmitted to the remotely coupledservers. The one or more servers may implement a health servicesapplication (in any suitable combination of hardware, firmware and/orsoftware) that analyzes recipient information, including a recipient'shealth history and detected health metric values, and determinesinterventions, which includes determining whether to intervene, and mayinclude determining how and/or when to intervene. Determininginterventions may include determining any of: whether it is necessary ordesirable to perform one or more actions for the recipient; whether tocommunicate information (e.g., health information) to the recipient; thecontent of such information; and one or more characteristics of thecommunication of such information, as described in more detail elsewhereherein. A communication from a health services application to a healthdevice as part of providing a health service, which may includespecifying one or more actions corresponding to one or moreinterventions, may be referred to herein as a “health communication.” Itshould be appreciated that some health communications may not bespecific to the health of the recipient, but may be directed to ageneral engagement with the recipient or specific to the operation ofthe health device, as is described in more detail elsewhere herein.

If, as part of determining interventions, it is determined that it isdesirable or necessary to perform one or more actions, the content ofthe health communication may specify the one or more actions and includean explanation of why the one or more actions should be performed. Thehealth communication then may be communicated to the health deviceaccording to health communication characteristics determined for thehealth communication, as described in more detail elsewhere herein.

The health services application may be configured to analyzeautonomously, at least in part, the recipient information to determineinterventions, for example, using predefined rules and/or a machinelearning engine (MLE). In some embodiments, in addition to, or as analternative to, autonomously analyzing recipient information todetermine interventions, the health services application may solicitand/or receive human input. For example, in some embodiments, at leastpart of the analysis and intervention determination may be performed bya trained practitioner. In some embodiments, the health servicesapplication may be configured to determine—based on recipientinformation, detected health metric values and rules corresponding tothe health condition for which services are being provided—what one ormore types of analysis (e.g., ruled-based, machine learning and/orhuman) are to be executed to determine interventions.

In some embodiments of the system described herein (e.g., embodiments inwhich machine learning is employed), as part of determininginterventions, recipient information may be analyzed to determine apreliminary list of one or more actions to instruct or recommendperforming as part of performing the service. This list may be filtered(e.g., using safety rules and/or a list of safe or unsafe action) toremove one or more actions that are deemed unsafe (e.g., clinicallyunsafe). Employing machine learning to autonomously or semi-autonomouslydetermine interventions may be more dynamic and flexible than employingpurely rules-based analysis, but the results also may be moreunpredictable than those from rules-based analysis. While suchunpredictability may be acceptable for some fields (e.g., marketing,games), it may not be acceptable for determining health interventions,especially for medical interventions. Accordingly, for safety reasons,it may be desirable to use safety rules and/or a list of safe or unsafeactions to filter a preliminary list of actions provided by the machinelearning. In some embodiments, the filtering may be applied beforegenerating the preliminary list (e.g., using machine learning); forexample, to rule out the possibility of any potentially dangerousactions being produced from the analysis.

In addition to filtering the preliminary list, the preliminary list maybe ranked, for example, before or after the preliminary list has beenfiltered by application of safety rules, and the ranked list may beanalyzed to determine a best one or more actions on the rankedlist—i.e., the one or more actions deemed best-suited to treat thehealth condition of the recipient based at least in part on therecipient information. The one or more actions that remain after thefiltering and selecting described above (sometimes referred to herein asthe definitive actions(s)) may be communicated in one or more healthcommunications to the health device, which then may communicate (e.g.,visually and/or audially) the one or more definitive actions to the userof the health device and/or may autonomously implement one or more ofthe definitive actions.

The health device may include one or more components to enable audial,visual and written correspondence between a user of the health device(e.g., recipient or caregiver) and the one or more remote devices and/orpractitioners, for example, in real-time, as described in more detailelsewhere herein.

In some embodiments, the health device may be configured to controlpower consumed by, and/or the thermal output of, the health device basedon detected temperatures within, or proximate to, certain regions of thehealth device and/or based on detected movement of the health device ora component thereof, as described in more detail elsewhere herein.

In some embodiments, the health device may be pre-configured (e.g.,customized) for a recipient, before delivery to the recipient, based oninformation about the recipient, which may include health informationabout the recipient. Such information, for example, in the form of arecipient profile, may be accessed in response to a purchase and/orordering of the health device by, or on behalf of, the recipient. Upondelivery, the user may be authenticated based on the recipientinformation, for example, using multi-factor authentication, asdescribed in more detail herein.

In some embodiments, a health services application (e.g., implemented onone or more servers) may be configured to determine—e.g., based onprevious recipient information provided to a health services applicationand/or previous health metric values detected from a health devicelocally coupled to the recipient—when detected health metric valuesconstitute an irregularity (i.e., an anomaly). For example, analysis ofthe most recently detected health metric values may determine that themost recent values were detected from a person other than the recipient,or that such values represent a significant and potentially dangerouschange in a recipient's condition. In response to detecting anirregularity, a notification may be sent to one or more entities, forexample, a responsible health professional, the health device (e.g., aspart of a health communication sent to the user of the health device)and/or to another known device (e.g., cell phone, home phone, laptop) ofthe recipient or a caregiver.

Illustrative embodiments of the system described herein will now bedescribed in relation to the drawings. It should be appreciated that thesystem described herein is not limited to the following illustrativeembodiments, as other embodiments, for example, variations of thefollowing illustrative embodiments, are possible, and intended to fallwithin the scope of the invention

FIG. 1 is a block diagram illustrating a system 100 for remotelyproviding a health service to a recipient, according to embodiments ofthe system described herein. Other embodiments of a system for remotelyproviding a health service to a recipient, for example, variations ofthe system 100, are possible and are intended to fall within the scopeof the invention.

The system 100 may include any of: a health device (e.g., mobile healthdevice 102), which may be locally coupled to a recipient (e.g., apatient) 104; one or more servers 108, 110 implementing a healthservices application 112; one or more recipient information databases114; other components (not shown); or any suitable combination of theforegoing. The servers 108, 110 and recipient info dbs 114 may reside ona network 106. The servers 108, 110 may host health services application112, and may be considered remote with respect to the health device 102(and thus the recipient 104) in the sense that the servers 108, 110communicate with the health device 102 over one or more network links(other than a direct NFC link, Blue Tooth link or the like) of network106. For example, the mobile health device 102 may be used at the homeof the recipient 104, whereas the servers 108, 110 may reside at amedical center or the like, or a separately located data center thereof.The servers 108, 110 may be part of a server cluster or other logicaland/or physical grouping of servers, and may include only one server ormore than two servers.

The network 106 may include any one or more of a variety ofcommunication media, switches and other components, including, forexample: a repeater, a multiplexer or even a satellite. Eachcommunication medium may be any of a variety of communication mediaincluding, but not limited to: a bus, a wire, an optical fiber, airand/or other type of communication medium. The network 106 may includeat least a portion of the Internet, a satellite-based network, a mobileor land-based telephony network, a proprietary intranet, another type ofnetwork, or any suitable combination of the foregoing. Components of thenetwork 106 or components connected thereto may be configured tocommunicate in accordance with any of a plurality of technologies,including, for example: GSM (e.g., 2G, 3G, LTE, 5G), TCP/IP, UDP,Ethernet, GIGE (Gigabit Ethernet), other Local Area Network (LAN)protocols, Wide Area Network (WAN) protocols, file transfer protocols,OSI protocols, SCSI, ESCON, Fibre Channel (FC), iSCSI, FCoE, NVMe overFabric (NVMf); other technologies, or any suitable combinations of theforegoing, each of which may have one or more associated standardspecifications.

The mobile health device 102 may include one or more health sensors 103to monitor (in some embodiments using one or more coupled accessories)values of one or more health metrics of the recipient 104 such as, forexample, blood glucose level and blood pressure, e.g., as described inmore detail elsewhere herein. The one or more health sensors 103 andaccessories thereto may include any of: a blood glucose meter, bloodpressure monitors (e.g., including a wrist monitor and/or a cuff), anelectronic scale, sleep monitor, fitness activity tracker, thermometer,catheter, subcutaneous sensor, syringe, tube, wire, stethoscope,electrode (e.g., an EKG electrode), patch, other health sensors and/oraccessories, or any suitable combination of the foregoing.

The health device 102 may be configured (e.g., with one or more networkinterface components) to communicate detected values of health caremetrics to health services application 112. The health servicesapplication 112 may be configured to analyze the received health metricvalues along with other recipient information from recipient informationdbs 114 to determine interventions, as described in more detailelsewhere herein. The health services application 112 may communicateintervention information in one or more health communications to thehealth device 102. Each health communication may describe one or moredefinitive actions to be performed by the recipient 104 or a caregiverof the recipient and/or one or more definitive actions to be performedor controlled autonomously by the health device 102.

The health device 102 may be configured with one or more audial, visualand/or tactile output technologies to communicate health communicationsand/or other information to a user of the health device 102 (e.g., therecipient or caregiver). The health device 102 also may be configuredwith one or more audial, visual and tactile input technologies to allowthe user of the health device 102 to input information associated with ahealth service, e.g., to be communicated to the health servicesapplication 112. The health device 102 further may be configured toimplement one or more conversion technologies for converting informationfrom one form of media and/or format thereof (e.g., audio, video or textencoded in accordance with a particular technology standard) to anotherform of media and/or format thereof. One or more of these conversiontechnologies may be applied to information received from the user of thehealth device; e.g., to be sent to the health services application 112;and one or more of these conversion technologies may be applied toinformation received from the health services application 112 or anotherremote source; e.g., to be presented to the user of the health device.Audial, visual and tactile input and output technologies, andconversions therebetween, are described in more detail elsewhere herein.

The health device 102 may be pre-configured (i.e., before delivery tothe recipient or caregiver thereof), authenticated and activated asdescribed in more detail elsewhere herein. Further, power consumptionand thermal output of the health device 102 may be controlled asdescribed in more detail elsewhere herein. The health device 102 may beimplemented as health device 200 described in relation to FIGS. 2A-2D,which will now be described.

FIG. 2A is a block diagram illustrating a schematic representation of amobile health device 200, according to embodiments of the systemdescribed herein. Other embodiments of a mobile health device, forexample, variations of the mobile health device 200, are possible andare intended to fall within the scope of the invention. FIG. 2A includesvarious icons to illustrate a certain functionality and/or capabilities,but it should be appreciated that such icons do not necessarily reflectthe physical attributes of the underlying components implementing thefunctionality or capability.

The mobile health device 200 may be physically configured for desktop orhandheld use, and may have a form factor at least similar to that of anelectronic tablet, notepad, personal digital assistant (PDA) or smartphone, as well as other form factors. The mobile health device 200 mayinclude any of: wireless connectivity components 202, which may includea wireless antenna 204 and a wireless chipset 206; a controller (e.g.,main processor) 208; audio components 214, which may include a speaker210 and a microphone 212; a rechargeable battery 216; a charger plug218; a charging cable 220; one or more motion sensors 222; an externalplug 224; one or more temperature sensors 228; a reader module 230; anexternal health sensor (e.g., test strip 234), including a test samplearea 232; camera components 236; a display screen (not shown); othercomponents; and any suitable combination of the foregoing.

The wireless connectivity component 202 may be configured to providewireless communication between the mobile health device 200 and otherdevices, for example, the servers 108, 110, to communicate with thehealth services application 112. The wireless chipset 206 may beconfigured (e.g., physically, electronically programmed and/orprogrammed with firmware and/or software) to control (perhaps incombination with, or under direction of, the controller 208) processingof wireless communication sent to, and received from, other devicesthrough the antenna 204. The wireless connectivity component 202 alsomay be configured to exchange information with an accessory of a healthdevice, for example, a wrist monitor, patch or subcutaneous component.

The audio components 214 may be configured to receive and transmit audiosignals, for example, using the microphone 212 and the speaker 210,respectively. The controller 208 may include logic to control and/orprocess audio communications to and from the audio components 214, forexample, audio content in health communications received via thewireless connectivity components 202, or converted from text content ofsuch health communications, and bound for the audio component 214. Theone or more motion sensors 222 may be configured to detect motion of thehealth device 200, and each motion sensor may be any of a variety ofmotion sensors configured to detect different types of motion,including, for example, a gyroscope, magnetometer, accelerometer, or aGPS system. Each of the one or more temperature sensors 228 may be anyof a variety of types of temperature sensor configured to detect atemperature in one or more regions internal and/or external to thehealth device 200.

In the illustrative example of FIG. 2A, the reader module 230 may be aglucose test strip reader configured to receive the test strip 234,where the test sample area 232 is configured to receive blood of a user.Any of a variety of other readers that can be accommodated on the healthdevice 200 may be included therein, in addition to, or in place of, thereader module 230.

In some embodiments, the health device 200 may be configured to includeone or more thermal buffers (e.g., air/space, insulating material)between any one or more health sensors (e.g., the reader module 230) andone or more other components of the health device 200. Including thebuffers may be done to thermally insulate a health sensor from the oneor more other components so that heat generated by operation of theother components does not affect operation of the health sensor, forexample, the accuracy of the values detected thereby.

The external plug 224 may be configured to receive a connector (e.g.,cable, wire) of any of a variety of types of devices, includingaccessories to the health device 200. For example, a blood pressure cuffmay be connected to the health device 200 through the external plug 224,for example, to convey information from the blood pressure cuff (orother accessory) to the controller 208 and/or instructions from thecontroller 208 to the blood pressure cuff (or other accessory). Thecamera component 236 may include a camera and associated logic forcapturing video and/or still images, conveying such video and/or imagesto the controller 208 (or other components) and/or receiving information(e.g., instructions) from the controller 208 (or other components(s) ofthe system), for example, in connection with providing health servicesas described in more detail elsewhere herein.

The controller 208 may include memory and one or more CPU cores and/orother computational components, on which any of a variety of firmware,operating systems (OSs) and other software may execute to implementfunctions of a health device described herein. The controller 208 may becoupled with, and configured to control, one or more other components ofthe health device 200, for example, any of the components describedherein. The controller 208 may include one or more sub-components (e.g.,logic) configured to perform one or more specific functions, forexample, one or more methods, steps or sub-portions thereof described inmore detail elsewhere herein.

FIG. 2B is a plan view of a mobile health device 231 (e.g., the healthdevice 200), according to embodiments of the system described herein.Other embodiments of a mobile health device, for example, variations ofthe mobile health device 231, are possible and are intended to fallwithin the scope of the invention. FIG. 2B includes various icons toillustrate certain functionality and/or capabilities, but it should beappreciated that such icons do not necessarily reflect the physicalattributes of the underlying components implementing the functionalityor capability.

The mobile health device 231 may include any of: a reader module 232(e.g., the reader module 230); a camera component 235 (e.g., the cameracomponent 236); wireless connectivity components 236 (e.g., the wirelessconnectivity components 202); a battery indicator 238; a wireless signalindicator 240; an alarm indicator 242; health communication content 244(e.g., instructions); a notification 246; a control button 248; acharger plug 250; an external plug 252 (e.g., the external plug 224); adisplay screen 254; and a side button 256.

The alarm indicator 242 may be controlled (e.g., by the controller 208)to visually indicate an alarm, for example, in response to a healthcommunication, as described in more detail elsewhere herein. The displayscreen 254 may be controlled (e.g., by the controller 208) to displayany of a variety of information in connection with providing a healthservice, for example, the health communication content 244 and thenotification 246. The control button 248 and the side button 256 may beconfigured to provide any of a variety of functionality in response tobeing pressed once, pressed multiple times in rapid succession and/orheld, including, for example, screen and control navigation, poweron/off, component or functionality activation/deactivation, volumecontrol, brightness control, health service functionality, otherfunctionality or any suitable combination of the foregoing.

In some embodiments, the mobile health device 200 may be configured tobe capable of being docked on a base station, e.g., for charging and/ordesktop use, for example, as illustrated in FIG. 2C. FIG. 2C is aperspective view 260 of a mobile health device 261 (e.g., the mobiledevice 200) mounted on a base station 263, according to embodiments ofthe system described herein. Other embodiments of a mobile health devicemounted on a base station for the health device, for example, variationsof the mobile health device 261 and base station 263, are possible andare intended to fall within the scope of the invention. FIG. 2C includesvarious icons to illustrate certain functionality and/or capabilities,but it should be appreciated that such icons do not necessarily reflectthe physical attributes of the underlying components implementing thefunctionality or capability.

The mobile health device 261 may be the same as or similar to the mobilehealth device 231, and may include any of the components thereof. Forexample, the mobile health device 261 may include a screen 263 fordisplaying health communication content 262, 264. The base station 263may include any of: wireless connectivity components 266; and externalplugs 268, 270 for externally coupled accessories, power and/orcharging.

FIG. 2D is a block diagram illustrating a controller 280 (e.g., thecontroller 208) of a health device (e.g., the health device 200),according to embodiments of the system described herein. Otherembodiments of a controller of a health device, for example, variationsof the controller 280, are possible and are intended to fall within thescope of the invention. The controller 280 may include any of: medialogic 282; power control logic 284; telephony logic 286; authenticationlogic 288; other logic; or any suitable combination of the foregoing.

The media logic 282 may include any of: audial and/or visual encodinglogic for encoding audio, video and still images captured by amicrophone or other audio capture device (e.g., the speaker 212) and/orcamera (e.g., the camera 236) or other video/image capture devices ofthe health device; audial and visual decoding logic for decoding audio,video and still images for rendering on a speaker (e.g., the speaker210) and/or display screen (e.g., the display screen 254) on the healthdevice; media type conversion logic for converting between types ofmedia (e.g., text-to-speech converter, speech-to-text conversion); andmedia format converting logic for converting from one media format toanother; for example, from a serialized video format to a format fordisplaying on a display screen. The media logic 282 may be configured tocontrol the audio components 214 and/or the camera components 236, andmay be utilized to perform one or more methods, steps, or portionsthereof described herein, in relation to using media (e.g., audial data,visual data or textual data) as part of providing a health service.

The power control logic 284 may be configured to control powerconsumption and/or thermal output of one or more components, forexample, as described in more detail elsewhere herein. The telephonylogic 286 may be configured to perform one or telephony functions, forexample, in connection with exchanging communications between the healthdevice and a health services application, as described in more detailelsewhere herein. The authentication logic 288 may be configured toauthenticate a user (e.g., a recipient) of the health device, forexample, as described in more detail elsewhere herein.

FIG. 3A is a data flow diagram illustrating a system 300 for remotelyproviding a health service to a recipient, according to embodiments ofthe system described herein. Other embodiments of a system for remotelyproviding a health service to a recipient, for example, variations ofthe system 300, are possible and are intended to fall within the scopeof the invention. The system 300 may include any of: a health servicedatabase(s) 302 (including, e.g., the recipient information db(s) 114);a health services application 312 (e.g., the health services application112); external health and recipient databases (dbs) 342; a health device344 (e.g., the health device 102); other devices 347; other components;or any suitable combination of the foregoing.

The health services application 312 may include a data aggregator 318that: receives raw recipient data 330 associated with a recipient 348, ahealth condition and/or a health service; aggregates the received data;and reconciles the aggregated data to produce reconciled data 316. Theraw recipient data 330 may include any of: a health history 332 of therecipient 348; biographical data 334 about the recipient 348; healthmetric values 340 of the recipient 348 detected by the health device344; information concerning actions performed by the recipient 348and/or the health device 344 (e.g., in response to one or more healthcommunications 346 communicated by health services application 312); andother information 336. The health history 332; biographical info 334 andother information 336 may be received from one or more health and/orrecipient databases 342, which may be external databases controlled ormaintained by other entities.

The health services application 312 may include a model generator 314that receives the reconciled data and generates a health data model 304,which the health services application 312 may store in the healthservices db(s) 302. The health services application 312 also may storerecipient data 303 in the health services db(s) 302. The recipient data303 may include the raw recipient data 330 and/or data derivedtherefrom, e.g., the reconciled data 316 or a partially reconciledversion of the raw recipient data 330.

FIG. 3B is a block diagram illustrating a data structure 350 that may beat least a portion of the health data model 304, according toembodiments of the system described herein. Other embodiments of a datastructure for a portion of a health data model, for example, variationsof the data structure 350, are possible and are intended to fall withinthe scope of the invention. The data structure 350 may include aplurality of entries (e.g., rows) 360 a-c, each entry corresponding to aset of one or more pieces of information corresponding to a time (orperiod of time) specified in time column 352, for example, the time atwhich such information was recorded or obtained. It should beappreciated that more or less than three entries, as illustrated in FIG.3B, may be included in the data structure 350. For each entry, the dataset may include one or more pieces of data, each piece of data being avalue of a parameter for a particular parameter column, e.g., one ofparameter columns 354, 356, and 358. Such parameters may includeparameters for demographic information about the patient (e.g., age,weight, gender), health metric values (e.g., any of those describedherein), health device information (e.g., last time used), actionsperformed by the user, and other information, interventions determinedfor the recipient, health communications communicated to a mobile healthdevice, actions taken by the recipient, the timing, duration andexpiration of interventions and/or actions, other parameters or anysuitable combination of the foregoing.

A first entry 360 a may represent a most recent time or period of time,and the remaining entries may represent older times or periods of time.In some embodiments, the first entry may be considered the current stateof health of the recipient, and the remaining entries the historicalhealth data for the patient, and collectively all of the entries may beconsidered to represent a chronology of the recipient's state of health.In some embodiments, a value is not included for every parameter column.For example, the raw recipient data 330 may have included informationabout an action performed, but not include any health metric values, inwhich case a resulting entry in the data structure 350 may not includeany health metric values. In some embodiments, each entry in the datastructure includes a value for every parameter. For example, for someparameters, even if a new value has not been received as part of the rawrecipient data 330, a default value may be included for the entry forthe parameter; e.g., a most recent value detected for the parameter. Forexample, if the raw recipient data 330 includes information about anaction performed, but does not include any health metric values, a mostrecent value (e.g., average blood pressure) may be used as a defaultvalue for the entry.

In some embodiments, one or more parameters have a value that neverchanges or seldom changes (e.g., gender) or can automatically bedetermined (e.g., age), in which case the value may be the same in eachentry of the data structure 350 and/or a header may be provided thatdefines the values of such parameters.

Is should be appreciated that, although data structure 350 isillustrated as a table, any of a variety of other types of datastructures may be used, including an object-oriented data structure,linked list, other type of data structure or suitable combination of theforegoing, and there may be more than one such data structure. Further,one or more indexes may be created for any of the columns/fields orother data elements of such data structures (e.g., data structure 350).

It should be appreciated that the health services db(s) 302 may includemultiple ones of the health data model 304 (e.g., including the datastructure 350 or a portion thereof), each health data modelcorresponding to a specific recipient. Further, the health servicesdb(s) may include data structures that include information resultingfrom combining information described above from multiple recipients.

Returning to FIG. 3A, the health service db 302 also may include healthtreatment rules 306, recipient device information 307, safety rulesand/or safety lists (e.g., a safe action list, described in more detailelsewhere herein) 308, described in more detail elsewhere herein. Therecipient device information 307 may include information about one ormore health devices of the patient including, for example: model, serialnumber, operating system and version, firmware and version, othersoftware and versions, owner or lessee, date of purchase, features,technical specifications, current and past locations, etc. It should beappreciated that the health services db(s) 302 may include recipientdevice information for multiple recipients.

The health treatment rules 306 and the safety rules/lists 308 may bedefined (at least initially) by a human and/or by automated processes.In some embodiments, each of the sets of rules/lists 306, 308 may remainstatic until modified by a human or automated process. The healthtreatment rules 306 and the safety rules/lists 308 may not be specificto any one recipient, but rather, applied for multiple (e.g., all known)recipients. In some embodiments, a machine learning engine (MLE), afterbeing initially configured, may autonomously update one or more of theserule sets/lists based on iterative calculations made each time thehealth metric values 340 are received and processed by the healthservices logic 320. Furthermore, the data aggregator 318 and the modelgenerator 314 may update the reconciled data 316, the recipient data 303and/or the health data model(s) 304 from time to time, in response tonew raw recipient data. Furthermore, the MLE 326 may be configured toupdate functionality of the MLE 326 (e.g., weights for its layers and/orgates if it is an artificial neural network) and/or the health treatmentrules 306 based on new raw recipient data, for example, as described inmore detail elsewhere herein.

The health services logic 320 may include analysis selection logic 322that receives the health metric values 340 from the health device 344for a recipient, and accesses the health data model 304, the healthtreatment rules 306, and/or the recipient data 303, and perhaps otherinformation in the health service db 302. The health services logic 320may be configured to determine, based on the health metric values 340and information accessed from health service db 302, what type ofanalysis to perform to determine interventions. The type of analysis mayinclude applying predefined rules-based logic, machine learning or humananalysis. Based on the determination of analysis type, the healthservices logic 320 may control rules analysis logic 324 or the MLE 326to determine interventions based on the health metric values 322 andinformation from the health services db(s) 302; or the health serviceslogic 320 may prompt (e.g., via a user interface) a trained practitioner328 (e.g., doctor, nurse, paramedic, physical trainer, health coach,etc.) to analyze received values and available information to determineinterventions.

It should be appreciated that the qualifications for a trainedpractitioner will depend on the health condition being serviced (e.g.,treated) and perhaps contractual relationships between the recipient andentities or organizations (e.g., medical center, clinic, insurancecompany, university, rehabilitation center, wellness center, physicaltrainer, etc.) with which the practitioner and/or recipient isaffiliated.

The analysis type selected by the analysis selection logic may depend ona variety of factors, including, for example: the one or more healthconditions being serviced; the health history of the recipient,generally and with respect to the one or more health conditions,including any recent trends in the health history; demographicinformation about the recipient, including, age, gender, race,residential location; most recent health metric values, contractualobligations, etc. The factors may be gleaned from the health metricvalues 340, the health data model 304, the recipient data 303 and/or thehealth treatment rules 306. It should be appreciated that a differenttype of analysis may be selected at different times for a same recipientand health condition. For example, if the health metric values 340, thehealth data model 304, the recipient data 303 and/or the healthtreatment rules 306 reflect a clearly typical and/or benign condition ofthe recipient (e.g., typical blood glucose levels for the recipient),the rules analysis logic 324 or the MLE 326 may be selected and engaged.However, if the health metric values 340 and information from the healthservice db 302 reflect a possibly significant change in a condition ofthe recipient, such as a severe condition and/or an irregularity (e.g.,a spike in the blood glucose level of the recipient), human evaluationby a trained practitioner (e.g., a medical doctor) may be selected, andthe practitioner 328 may be engaged. For example, if the health metricvalues reflect a serious enough (or potentially serious enough) medicalcondition, it may be desirable to contact a physician or other doctorrather than relying on an autonomous system.

It should be appreciated that at least some of the logic involved inselecting the analysis type and in determining interventions may becodified within information included in the health service db 302, e.g.,in the data model 304, and the health treatment rules 306, the safetyrules/lists 308

The health services logic 320, more specifically, the rule analysislogic 324 and/or the MLE 326, and/or the trained practitioner 328 maydetermine interventions based on the health metric values 322 andinformation from the health services db(s) 302; and may produce one ormore of the health communications 346 based on determinedintervention(s) that are sent to the health device 344 and/or one ormore of the other devices 347 (e.g., a mobile phone, laptop computer orother device of a recipient). Determining intervention(s) may includedetermining a timing and/or expiration of one or more actions to performfor the intervention. For example, it may be determined that a patientshould take a medication, but only if the medication is taken between8:00 pm and 10:00 pm, an estimated time approaching a bedtime of apatient. Thus, the selected component(s) of health services logic 320and/or the practitioner 328 may determine a timing of 8:00 pm to send ahealth communications to display a message to the patient and anexpiration of 10:00 of the message. Thus, the health communication 346may be sent at 8:00 pm, causing a message to be displayed on a screen ofthe health device instructing the patient to take the medication, until10:00 pm, at which time the message may stop displaying, and perhaps anew message is displayed instructing the patient to take the medicationwhen the patient wakes up in the morning.

The health services logic 320 may be configured to record informationassociated with an invention determination, including whether it wasdetermined that an intervention (including a communication and/or one ormore actions) will occur, and if so, the determined content, timing (ifany), expiration (if any); characteristics of the health communications,and other contextual information associated with the intervention,including the value of one or more state variables and healthinformation parameters that influenced the intervention determination.Such information may be recorded in the health services db(s) 302,including, for example, as part of the data model 304 and/or therecipient data 303.

The health communication(s) 346 may include content specifying one ormore actions for the health device and/or recipient (or caregiver) toundertake, timing and expiration for the one or more actions, and valuesfor health communication characteristics, described below.

FIG. 4 is a diagram illustrating health communication characteristics400, according to embodiments of the system described herein. Otherembodiments of health communication characteristics, for example,variations of the characteristics 400, are possible and are intended tofall within the scope of the invention. The health communicationcharacteristics may be stored in one or more data structures and may becodes in software and/or firmware.

The characteristics 400 of a health communication may include any of:purpose 404; communication type 406; media type 408; interventionanalysis type (not shown); other characteristics; and any suitablecombination of the foregoing. The purpose characteristic 404 may specifya purpose for the health communication. One of a plurality of purposecharacteristic values 410 may include, for example, “health,”“engagement” and “device operation.”

A purpose characteristic value 410 of “health” may indicate that thepurpose of a health communication is specific to the health of therecipient for whom the communication is sent., A purpose characteristicvalue 410 of “engagement” may indicate that a health communication isfor general engagement of the recipient, as opposed to being specific toa health condition or the health device itself. For example, the healthservices application 312 may be configured to determine when there hasbeen a long period of inactivity and may send a health communication tosimply check-in on the general status of the recipient—e.g., ask why therecipient has not used the device yet, or has not used the device insome time, or confirm the recipient is still reading or hearingcommunications and/or still using the health device.

A purpose characteristic value 410 of “device operation” may indicatethat a health communication is specific to the functioning of the healthdevice, and may include an additional sub-value from amongdevice-functioning sub-values 418, e.g., “manual and help,”“troubleshooting” and “upgrades.” For example, a device-functioningsub-value of “manual and help” may indicate that the purpose of a healthcommunication is to provide device operation help or user-manualinformation to the recipient. A device-functioning sub-value of“troubleshooting” may indicate that the purpose of a healthcommunication is to provide technical troubleshooting for an operationalproblem the recipient is having with the health device. Adevice-functioning sub-value of “upgrade” may indicate that the purposeof a health communication is to provide a software or firmware upgradefor the health device.

A plurality of communication type characteristic values 414 may specifya type of a health communication, for example, a notification (e.g.,reminder, alert), instruction, inquiry, feedback request, liveconversation, and automatic conversation. A notification type ofcommunication may specify a reminder, alert or other type ofnotification for a recipient; for example, a reminder to take amedication or exercise, or an alert that blood pressure is trendinghigher and approaching dangerous levels. An instruction type ofcommunication may specify an instruction for a recipient, for example,to take insulin because most recent blood glucose measurements were toolow or too high, or to take photos or videos of a part of therecipient's body, food a recipient has been, is, or will be eating, or adocument (e.g., a paper drug prescription),medication label, etc. . . .

An inquiry type of communication may ask questions to the recipient, forexample, about how they feel, recent activity or how closely they havebeen following a prescribed treatment. A feedback request type ofcommunication may solicit feedback from the recipient following anintervention action. A live conversation type of communication mayprovide a most recent response from a practitioner as part of an ongoingconversation with the recipient; whereas an automatic conversation typeof communication may provide a most recent automated response (e.g.,generated by the rules analysis logic 324 or the MLE 326); e.g., from achatbot, as part of an ongoing conversation with the recipient.

Accordingly, the communication type characteristic values 414 mayinclude, for example, values of “notification”, “instruction,”“inquiry,” “feedback request,” “live conversation,” “automaticconversation” or other communication types.

A plurality of media type characteristic values 416 may specify the typeof media used to convey a health communication to a health device, forexample, text, audio (e.g., voice, sounds), images, video, or a viablecombination of one of the foregoing. Accordingly, the media typecharacteristic values 416 may include, for example, values of “text,”“audio,” “images,” “video,” or any suitable combination of theforegoing.

As noted above, the characteristics 400 of a health communication mayinclude an intervention analysis type (not shown). The interventionanalysis type may specify the type of intervention analysis applied(e.g., by the health services logic 320 of the health servicesapplication 312) that resulted in a health communication, or morespecifically, the one or more interventions specified in the healthcommunication. Values of an intervention analysis type may include, forexample, rules-based analysis, MLE, human analysis, another analysistype, or any combination of the foregoing.

The health services logic 320 (e.g., the rule analysis logic 324 and/orthe MLE 326) and/or the practitioner 328 may be configured to determinevalues for the health communication characteristics based on informationobtained from the health services db(s) 302 and the health metricvalue(s) 340. For example, MLE analysis may determine that a healthcommunication has a purpose of “treatment,” a communication type of“instructions” and a media type of “audio;” i.e., that a healthcommunication should be sent to the health device including aninstruction for treatment in the form of audio recorded by apractitioner, which may be played as speech on the speaker of the healthdevice and/or converted to text and displayed on a screen of the healthdevice. As another example, a rules-based analysis may determine that ahealth communication has a purpose of “diagnosis,” a communication typeof “notification” and a media type of “text”; i.e., that a healthcommunication should be sent to the health device including anotification of a diagnosis in the form of text, which may be displayedon a screen of the health device and/or played as speech on the speakerof the health device.

It should be appreciated that the decision of whether to convert audiocontent of a health communication to text and display it on a screen ofthe health device, or conversely to convert text to speech and play on aspeaker of a health device, may be controlled by a user of the healthdevice (e.g., the recipient). For example, the user may control whetherthe media format is converted using a graphical user interface presentedon the health device and/or voice or tactile input of the health device.In some embodiments, the manner in which content is presented to a useris controlled by one or two parameters that may be pre-configured aspart of the pre-configuration process described in more detail elsewhereherein. In some embodiments, the health communication itself may specifywhat media form the content is to be conveyed from the health device tothe user, which may be different than the form in which the content isencoded and transmitted to the health device. For example, there may beseparate health communication types for: media type for transmission tothe health device; and media type for communicating from the healthdevice to the user, and the health services logic 320 may be configuredto set such values based on information obtained from the healthservices db(s) 302 and the health metric value(s) 340. In someembodiments, values for conveying content from the health device to theuser set during pre-configuration may be overridden by the valuesspecified in a health communication or by the user of the health device;and values specified in a health communication may be overridden byvalues entered by a user of the device.

The characteristics 400, potential values thereof, and actual valuesattributed to a health communication (e.g., one of the healthcommunication(s) 346) transmitted from a health application service(e.g., the health services application 312) to a health device (e.g.,the health device 344) may be recorded, for example, in the healthservices db(s) 302.

FIG. 5 is a flow diagram 500 illustrating remotely providing a healthservice to a recipient, according to embodiments of the system describedherein. Other embodiments of remotely providing a health service to arecipient, for example, variations of processing illustrated by the flowdiagram 500, are possible and are intended to fall within the scope ofthe invention.

In a step 502, the health service may be configured; i.e., initializedor set-up. For example, a recipient health model may be constructed, forexample, as described in more detail elsewhere herein. Furthermore, inembodiments in which an MLE (e.g., the MLE 326) is used, the MLE may bepre-configured; e.g., trained or primed, for example, as described inmore detail elsewhere herein. In some embodiments, the step 502 mayinclude predefining one or more health communication characteristics,for example, any of the health communication characteristics describedin relation to FIG. 4; and the health communication characteristics maybe associated with one or more interventions and/or communicationsassociated therewith.

In a step 504, a health device (e.g., the health device 200) of therecipient may be preconfigured before delivery of the health device tothe recipient, for example, based at least in part on a recipientprofile, which may include health information associated with therecipient; e.g., as described in more detail elsewhere herein.

In a step 506, operation of the health device may be managed. The step506 may include authenticating a user of the health device as being anintended recipient/patient before activating the health device (i.e.,enabling further use), for example, as described in more detailelsewhere herein. The step 506 also may include controlling powerconsumption and/or thermal output of the health device, as described inmore detail elsewhere herein. It should be appreciated that the step 506may be performed concurrently, at least in part, with other stepsillustrated by the flow diagram 500.

In a step 508, health metric values of the recipient may be monitored,for example, by one or more health sensors, where the health metrics maybe any of the health metrics described herein. For example, values ofone or more health metrics may be detected continuously, orintermittently, e.g., periodically according to a set schedule or inresponse to user input. For example, a CGM may continuously detectglucose levels within a patient, or a blood pressure measurement using ablood pressure cuff may be used to detect blood pressure from a patientonce a day or at the request of a physician.

In a step 510, other input associated with the recipient may bereceived. For example, the recipient may input text, audio, video orstill images using input devices, for example, a keyboard, mouse, trackball, microphone, camera or other input device, including any of thosedescribed herein. In some embodiments, the other input may be input inresponse to a health communication. For example, the input may be apicture or video of a foot of a diabetes patient in response to aninstruction included in a health communication from a health servicesapplication to photograph the foot of the patient. It should beappreciated that step 510 may be performed concurrently, at least inpart, with the step 508.

In some embodiments, the other input received in the step 510 mayinclude environmental or other contextual values, including, forexample, time of day, whether it is daytime or nighttime; currenttemperature, whether a recipient is awake or asleep; whether therecipient is currently or was recently engaged in strenuous physicalactivity; when the recipient last ate; etc. Such environmental or othercontextual values may be detected by a health device or entered into thehealth device by a recipient in connection with the health metric valuesbeing detected.

In a step 512, monitored values, and perhaps other input received at thehealth device, may be communicated to a health services application(e.g., the health services application 312) located remotely from thehealth device (e.g., on one or more servers), for example, using one ormore of the network interface components described herein or by anothermeans. In some embodiments, content input by a user may be convertedfrom one media form (e.g., text or speech) in which it was received fromthe user to another media form (e.g., speech or text), and may beencoded in a different format than the format in which the content wasreceived, for transmission to one or more servers on which a healthservices application resides. Converting the form of media or format ofcontent input into the health device may be performed using audio logicand components described elsewhere herein.

In a step 513, the health data model 304, health treatment rules 306 andperhaps other data in the health services db(s) 302, and/or MLEparameters (e.g., weights of neural network layer or gates) may beupdated based on the monitored health metric values(s) and/or otherinput received (e.g., actions performed) in the step 512. For example,the MLE may be configured to learn about the efficacy of actionsperformed in response to health communications. The learning may includecomparing values of previous values of health metrics against values ofsuch health metrics after actions prescribed by an intervention aretaken. For example, the health services logic 320 (e.g., the MLE 326)may have produced a health communication 346 that specified multipleactions for a recipient (e.g., patient) 348 to take to reduce bloodpressure. The recipient 348 may have undertaken the actions, which maybe recorded in the step 522 and received as part of the other input(e.g., the action(s) performed 338) in the step 510. Furthermore,additional values of blood pressure metrics (e.g., included in healthmetrics 340) may have been received by the health device 344 in the step508 since the actions were performed.

The recipient health models 304 and recipient data 303 of one or morerecipients may be updated based on the actions(s) performed 338 inresponse to the health communication 346 and health metric values (e.g.,blood pressure values) detected since the other actions were performed,as well as other raw recipient data 330 received from other healthdevices of other recipients and/or external health and patient db(s) 342since the action were performed. The updating may include determining aproper chronology of events and measurements from difference sources, asdescribed elsewhere herein.

The MLE 326 may analyze the effectiveness of the previously prescribedactions intended to treat a health condition (e.g., reduce bloodpressure) by comparing the updated health metric values and otherupdated information to health metric values and other informationreceived before the prescribed actions were performed. The parameters(e.g., weights) of the MLE 326 may be adjusted accordingly (in additionto determining interventions based on the updated information), eitherautomatically and/or manually. An iterative performance of the foregoingover time should improve the accuracy of the MLE 326 in prescribingoptimal interventions. It should be appreciated that step 513 may beperformed at any time in relation to other steps of the method 500.

In a step 514, one or more interventions may be determined, for example,based on recipient health information, including detected health metricvalues, and/or one or more treatment rules. Determining interventionsmay include determining any of: whether it is necessary or desirable toperform one or more actions for the recipient; whether to communicateinformation (e.g., health information) to the recipient; the content ofsuch information; and one or more characteristics of the communicationof such information, as described in more detail elsewhere herein. Oneor more interventions may be determined autonomously and/or by humananalysis, for example, as described in more detail elsewhere herein.

The step 514 may include determining that health metric valuesconstitute an irregularity (e.g., an anomaly) with respect to previoushealth metric values detected from a recipient, for example, asdescribed in more detail elsewhere herein. The step 514 additionally mayinclude determining one or more interventions in response to detectingan irregularity, including, for example, sending communications to oneor more entities (e.g., the recipient or a practitioner) as described inmore detail elsewhere herein.

In a step 516, in response to determining one or more interventions,information may be communicated to the health device, for example, apart of a health communication, which may specify one or more actionscorresponding to the determined one or more interventions. The healthcommunication may be communicated to the health device according tohealth communication characteristics determined for the healthcommunication in the step 514. In some embodiments, multiple healthcommunications may be scheduled at different times based one thedeterminations made in the step 514.

In a step 518, in response to receiving information in the step 516, thehealth device may communicate information to the recipient, for exampleusing a screen, speaker, visual indicator, and/or other output device ofthe health device. The information may specify one or more of theactions corresponding to the intervention(s), for example, in the formof a notification, instruction, inquiry, feedback request, and/or aportion of a live or automated conversation.

In a step 520, one or more actions corresponding to the one or moreinterventions, and specified in a health communication, may beperformed, for example, by the recipient, the caregiver and/or thehealth device itself. It should be appreciated that the one or moreactions corresponding to an intervention may range from very generaland/or long-term actions to very specific, short-term actions. Forexample, such an action may include adjusting a care regimen orlifestyle, e.g., over a period of time; or taking a video or image ofone or more parts of a patient's body, immediate surroundings, food,documents (e.g., paper prescriptions), medications, medication labels orother items. In embodiments in which images are taken, the method 520may include applying recognition software to an image before or afterthe image is captured by a camera to determine whether the image isconsistent with information in a health communication, and may beconfigured to reject the captured image and/or further instruct therecipient accordingly. For example, a message may be played or displayedto the user of the health device indicating rejection or acceptance ofthe images. The image recognition software may reside within and/or beexecuted by a controller (e.g., the controller 208) of the healthdevice.

In a step 522, performance of one or more actions may be recorded. Forexample, the health device may detect that an action is performed andrecord performance of the action. Such action may include, for example,detecting blood pressure, taking a picture of a body part, taking a bodytemperature. The performance of other actions may be specified by userinput and recorded. Such actions may include, for example: exercising,taking medication, observing a diet over a period of time. The foregoingdetected and input actions may be included with received user input ofthe step 510, and included in the other input communicated to the healthservices application in the step 512. After performance of the step 522,control may return to the step 508, described above.

In addition to actions performed in accordance with an intervention,other actions may be recorded as well, such as, for example, the user ofthe health device opening and/or clicking on an email message,responding to a text or otherwise interacting with the health device.

It should be appreciated that performance of some or all of the steps ofthe flow diagram 500 may be performed iteratively, for example, as partof providing a real-time remote health service to a recipient. Forexample, such one or more steps may be performed such that informationis exchanged at a rate at least similar to a rate at which informationmay be exchanged between a practitioner and recipient in an in-personmeeting.

FIG. 6 is a flow diagram 600 illustrating constructing a health datamodel, according to embodiments of the system described herein. Otherembodiments of constructing a health data model, for example, variationsof processing illustrated by the flow diagram 600, are possible and areintended to fall within the scope of the invention.

In a step 602, recipient data may be aggregated from multiple potentialsources. The recipient data may contain data described in more detailelsewhere herein, including the raw recipient data 330, which mayinclude any of: the health history 332 of the recipient 348; thebiographical data 334 about the recipient 348, the health metric values340 of the recipient 348 detected by the health device 344; informationconcerning actions performed by the recipient 348 and/or the healthdevice 344 (e.g., in response to one or more health communications 346communicated by the health services application 312); and otherinformation 336. The health history 332; the biographical info 334 andthe other information 336 may be received from one or more health and/orrecipient databases 342, which may be external databases controlled ormaintained by other entities. Furthermore, the recipient data mayinclude information gleaned from traditional “offline” data such asmedical claims, pharmacy claims and medical lab results, and may includedata that may influence health like geography, income, and ethnicityassociated with the recipient. The data from the different data sourcesmay be updated at different intervals, and may include imperfectidentification information and other errors.

In a step 604, the aggregated recipient data may be reconciled toproduce reconciled data (e.g., the reconciliation data 316). Reconcilingthe data may include normalizing recipient data into a similar dataschema so that the recipient data; e.g., patient identification, timeseries, medical diagnoses, health metric values, performed actionsand/or data measurement units, may be compared between data sources.Such reconciliation may include converting and formatting fields intocanonical forms for accurate comparison, which may involvestandardization of capitalization, punctuation, spacing, and numericpadding. Dates and times may be normalized to a single time zone foraccurate comparison. Other data, for example, health metric values, maybe converted to common units, e.g., metric vs. imperial. Reconciliationmay further include identifying and matching recipients across differentdata sources using either exact matches on combinations of fields and/orusing high-probability indirect matching. The fields may include, forexample: name, birth date, insurance numbers, employee ID, phone number,or email address. Indirect identity matching between disparate data setsmay rely on explicit matching logic. For example, “Bob” from one sourcemay be the same name as “ROBERT” from another. The system also mayleverage explicit language-specific name equivalencies. Matching alsomay be assisted by statistical correlations derived from large datasets. Other techniques for matching may be employed.

The reconciliation at the step 604 may include merging a chronology ofdata (e.g., health facts and interpretations) from the multiple datasources into a single merged absolute timeline.

In a step 606, a health model/profile (e.g., the health data model 304)may be built from the reconciled recipient data. The health model maymodel present and past health statuses of the recipient/patient. Thehealth model and underlying data thereof (e.g., the recipient data 303)may be used by an MLE, a rules-based engine and/or a practitioner todetermine interventions, as will be described in more detail elsewhereherein.

The processing illustrated by the flow diagram 600, includingaggregating and reconciling of recipient information and generation of apatient health data model or the like, may be repeated periodically, forexample, in accordance with a predefined schedule, and/or may beperformed in response to an event, for example, a user instruction.

As described elsewhere herein, in some embodiments, an MLE may be usedto determine interventions. FIG. 7 is a flow diagram 700 illustratingpreconfiguring such an MLE, according to embodiments of the systemdescribed herein. Other mechanisms for preconfiguring an MLE, forexample, variations of the processing illustrated by the flow diagram700, are possible and are intended to fall within the scope of theinvention.

In a step 702, one or more data elements may be selected from availablehealth data, for example, data available in the health services db(s)302, to serve as features of the MLE. That is, features deemed mostrelevant to determining an intervention for a health condition may beselected. For example, for a patient being treated for a form ofdiabetes, the following data elements may be used as features: age,gender, body mass index (BMI), average fasting blood glucose, percent oftime blood glucose is within a target range, average blood pressure, andlevel of physical activity. The number of features may be considered thenumber of dimensions of the one or more data sets (e.g., recipienthealth profiles) to be analyzed.

In a step 704, clusters may be identified from selected features. Forexample, a clustering algorithm may be applied to determine clusters foreach given feature from among a plurality of data sets (e.g., recipienthealth profiles). For example, clusters of individuals with similarblood glucose patterns could be identified using features including age,gender, and body mass index.

In a step 706, one or more features may be removed from the recipientdata, for example, to reduce the number dimensions of data to considerin determining interventions. For example, analysis may reveal that thevalue of one or more features are not determinative enough of anintervention; i.e., a strong correlation cannot be drawn between a valueof a feature and any potential intervention. For example, the featuresselected in the step 702 may have included the altitude of the residenceof the recipient, but analysis may have revealed that the altitude ofthe residence did not have a strong correlation to any other features orpotential interventions. Accordingly, the value of analyzing a featuremay be outweighed by the benefits of removing the feature from theanalysis to save resources (e.g., computational resources and memory).

In step 708, the MLE may be initialized. For example, initial weightsmay be set manually (perhaps randomly) for certain functional parametersof the MLE. For example, in an embodiment in which an artificial neuralnetwork (NN) is implemented by the MLE, initial weights may be manuallyset for various layers (e.g., input, output, hidden) or gates of the NNthat receive data sets (e.g. vectors) of health information.

In step 710, the MLE may be trained by running several data sets (i.e.,input vectors) of health metric values (e.g., test data) through the MLEand comparing results (e.g., the determined interventions) to correctinterventions based on the test data. That is, the correct or properintervention based on previous analysis of the data by experts may becompared to the intervention(s) (e.g., output value(s)) determined bythe MLE using known mathematical techniques. The calculated differencebetween the intervention(s) determined by the MLE and the correctintervention(s) may be used to tune (e.g., automatically) one or moreweights of the functional parameters of the MLE, thereby adjusting thefunction(s) performed by the MLE. Comparing interventions and adjustingweights may be executed iteratively until the accuracy of the MLE indetermining intervention(s) is deemed adequate (e.g., according to theresults of a loss function).

As described elsewhere herein (e.g., with respect to the step 504),providing a remote service according to embodiments of the systemdescribed herein may include configuring a mobile health device prior todelivering possession to a recipient. FIG. 8 is a flow diagram 800illustrating configuring a mobile health device prior to delivering themobile health device to a recipient, according to embodiments of thesystem described herein. Other embodiments of configuring a mobilehealth device prior to delivering the mobile health device to arecipient, for example, variations of the processing illustrated by theflow diagram 800, are possible and are intended to fall within the scopeof the invention.

In a step 802, a profile of the recipient may be accessed. The profilemay include health information about the recipient, and otherinformation about the recipient that may be desirable or necessary forpre-configuring functionality of the mobile health device of therecipient, and/or that may be used in some embodiments to enableauthentication of the mobile device upon delivery of the health deviceto the recipient. The profile may be created, maintained and/or accessedby a vendor of the health device or another entity in a contractualrelationship with the vendor or the recipient, e.g., a health care orfitness organization or facility, or by multiple entities pursuant to apartnership agreement or the like.

The recipient information from which the profile may be generated may befrom one or more data sources, which may be owned and/or controlled byanother entity. For example, such information may be obtained from theexternal health and patient db(s) 342 or from the health services db(s)302. Given the potentially sensitive nature of at least some of theinformation, particularly health information, about the recipient,certain security measures may be required and implemented as part ofobtaining the recipient information, generating the profile and/ormaintaining the profile. Some of these required security measures may bemandated by government regulations, e.g., HIPAA regulations.

The profile may be accessed, and perhaps generated, in response to apurchase or order of the health device by, or on behalf of, therecipient. For example, an ID and/or secure credentials of the recipientmay be presented at a time of the order or purchase, which may be usedto authorize access to the profile. The profile may specify one or moreother devices and/or contact information (e.g., email address, phonenumber) at which to contact the recipient to perform multiple-factor(e.g., two-factor) authentication of the recipient as the user of thehealth device at a later time. That is, the other devices and/or contactinformation may be registered to the recipient. The other device and/orcontact information may be provided at the time of purchasing orordering the device, or may have been provided earlier.

In a step 804, one or more parameters of a health device (e.g., thehealth device 200 or the health device 231) may be defined based oninformation in the profile, and, in a step 806, the health device may beconfigured based on the one on more parameter values. For example,accessibility features of the health device may be customized based oninformation about the recipient's hearing, vision or other physicalcapabilities. Furthermore, one or more parameter values of a healthsensor (e.g., CGM, blood pressure sensor, etc.) included in the healthdevice may be set based on information about a health condition of therecipient for which the health device is intended to be used to service.Other parameters may be defined (e.g., customized) based on an employer,insurer or service provider (e.g., doctor, trainer, coach) determinedfrom the recipient's profile. Such parameters may include, for example,the look-and-feel (e.g., branding) of the user interface, accesscontrols, and pre-loaded applications and capabilities.

In some embodiments, the health device may be configured withidentifying information about the recipient, which may be used toauthenticate the recipient as the user of the health device afterdelivering of the health device to the recipient, as described below.

As described elsewhere herein (e.g., with respect to the step 506),managing operation of a health device may include authenticating a userof a mobile health device. FIG. 9 is a flow diagram 900 illustratingauthenticating a user of a mobile health device, for example, prior toan initial use of the mobile health device by the user, according toembodiments of the system described herein. Other embodiments ofauthenticating a user of a mobile health device, for example, variationsof the processing illustrated by the flow diagram 900, are possible andare intended to fall within the scope of the invention. The processingillustrated by the flow diagram 900 may be implemented using theauthentication logic 288 of the controller 280 (e.g., the controller208).

In a step 902, possession of the health device may be given to therecipient or caregiver. For example, the health device may be given tothe recipient at the time of purchase or delivered to a residence orbusiness of the recipient.

In a step 904, a first communication may be sent from the health deviceto a health services application (e.g., the health services application312) or another remote entity responsible for authenticating the user ofthe health device. The first communication may be sent in response tothe health device being powered on, or in response to another action byan operator of the health device. The health device may be configured tosend the first communication in response to the action by the operator.The first communication may include information identifying the device(e.g., by a serial number), and may identify the device as belonging tothe recipient, for example, by supplying an ID, PIN and/or other uniqueinformation or credentials of the recipient.

In a step 906, a second communication may be sent from the healthservices application (or other authenticating entity) to another deviceand/or contact of the recipient. The second communication may be sent inresponse to receiving the first communication. The information withinthe first communication identifying the health device and/or the ownerof the health device may be used to access the recipient profile anddetermine the contact and/or other device information of the recipient,to which the second communication is directed. The second communicationmay include an access code (e.g., a one-time password (OTP)).

In a step 908, a third communication may be received at the healthservices application. In some embodiments, the third communication maybe from the health device. In such embodiments, to determine whether theuser device is authentic in a test step 910, it may be determinedwhether the third communication includes the access code transmitted inthe second communication. If the access code in the third communicationmatches the access code included in the second communication, then,control transfers to a step 914 where the identity of the user of thehealth device as the recipient may be deemed authentic, and use of thehealth device allowed. For example, the health device may be activatedin response to the authentication.

If it is determined in the step 910 that the access code in the thirdcommunication does not match the access code included in the secondcommunication, then control transfers to a step 912 where the device maynot be activated, i.e., use may not be allowed. That is, identity of thecurrent user of the health device may be deemed inauthentic and use ofthe device by the current user rejected.

In some embodiments, the third communication may be received from theother device and/or contact of the recipient. In such embodiments, itmay be determined in the step 910 whether the third communication wasreceived from the other recipient device and/or other contact registeredfor the recipient with the health services application. Thedetermination may be made by comparing the identity (e.g., serialnumber) of the source device or the identity of the sender (e.g., emailaddress or phone number) to the identity of the other device and/orcontact information of the recipient in the recipient profile of therecipient.

In embodiments in which the third communication is received from theother device and/or contact of the recipient, if it is determined in thestep 910 that the third communication was indeed received from the otherdevice and/or contact registered to the recipient, then, in the step914, the identity of the user of the health device as the recipient maybe deemed authentic, and use of the health device allowed. For example,the health device may be activated in response to the authentication. Ifit is determined in the step 910 that the third communication was notreceived from the other device registered to the recipient, then, in thestep 912, the device may not be activated, i.e., use may not be allowed.That is, identity of the current user of the health device may be deemedinauthentic and use of the device by the current user rejected.

As described elsewhere herein (e.g., with respect to the step 506),managing operation of a health device may include activating a mobilehealth device in response to detecting motion of the mobile healthdevice. FIG. 10 is a flow diagram 1000 illustrating activating a mobilehealth device in response to detecting motion of the mobile healthdevice, according to embodiments of the system described herein. Otherembodiments of activating a mobile health device in response todetecting motion of the mobile health device, for example, variations ofthe processing illustrated by the flow diagram 1000, are possible andare intended to fall within the scope of the invention. The processingillustrated by the flow diagram 1000 may be implemented using the powercontrol logic 284 of the controller 280 (e.g., the controller 208) incombination with the one or more of the motion sensors 222.

Processing begins at a first step 1002 where it is determined whether astart of motion has been detected. For example, the motion controlsensor 222 may detect motion of the health device 200 in one or moredimensions. If such motion has not been detected, then the step 1002will be repeated until such a motion is detected. In some embodiments,in addition to or as an alternative to the polling reflected by therepeated performance of the step 1002, the detection of motion may bereceived as an event or interrupt.

If the start of motion is detected in the step 1002, then controltransfers to a step 1004 where the motion may be recorded for apredetermined period of time, for example, for a period of time deemedsufficient to determine whether the motion may be indicative of anaction about to be performed. That is, a health device or a componentthereof (e.g., a health sensor) or accessory thereto may have one ormore motion profiles associated therewith. Each motion profile mayspecify a pattern and duration of motion indicative of the imminent useof the health device, e.g., to detect one or more values of healthmetrics. For example, the motion of a blood pressure cuff at a certaintrajectory after a long period of not moving at all may be deemedindicative of an imminent blood pressure measurement. In contrast,general motion of a glucose level reader of a mobile health device maynot be deemed indicative of an imminent use of the mobile health device,which may be frequently in motion as the recipient walks, drives orrides.

In a test step 1006, it may be determined whether the recorded motion isindicative of an imminent action, for example, the taking of bloodpressure with a blood pressure cuff. The determination may be made bycomparing the recorded motion of the health device 200, a componentthereof, or an accessory thereto, to one or more motion profiles of thehealth device 200, component or accessory. The profiles may be stored onthe health device 200 (for example, in a memory on the health device200, e.g., the memory of the controller 208) or on a remote one or moreservers on which a health services application resides. The comparisonmay be performed on the health device 200 itself, which may requireretrieving the one or more motion profiles if not already stored inmemory, or may be performed on the one or more servers, in which casethe recorded motion may be transmitted to the one or more servers to becompared.

If it is determined in the step 1006 that the recorded motion is notindicative of an imminent action, then control transfers to a step 1010,where it may be determined whether to continue recording motion. Forexample, it may be known (e.g., by the power control logic 284) from theone or more motion profiles associated with the device whether there aremotion profiles of longer periods of time to which to compare recordedmotion. If there are no such motion profiles, then control transfers toa step 1012 where recording is stopped. Following the step 1012, controlmay return to the step 1002, described above, to begin another iterationto detect a next start of motion.

If it is determined in the step 1010 to continue recording, then controltransfers back to the step 1004, described above, where motion maycontinue to be recorded for a predetermined period of time following bythe step 1006, described above, to determine if the recorded motion isindicative of an imminent action. That is, motion may be recorded for alonger and/or new period(s) of time, and then compared again to the oneor more motion profiles.

If it is determined in the step 1006 that the recorded motion isindicative of an imminent action (e.g., a detecting of health metricvalues), then control transfers to a step 1008 where the health device,or one or more components thereof, may be activated (e.g., powered onand/or initialized). Activating the device or components thereof whenaction(s) are imminent may avoid delays in performing functions (e.g.,detecting metric values, determining interventions, and otheractivities) that could be caused by trying to activate components whileperformance of these functions is initiated.

In some embodiments, the health device, or one or more componentsthereof, may be activated in response to detecting other actions, forexample, the connecting of one or more accessories to the health device.For example, the health device or one or more components thereof may bepowered on and/or initialized in response to detecting a blood pressurecuff being plugged into a plug (e.g., any of the plugs 218, 224, 250,252, 268 and 270) or a test strip (e.g., the test strip 234) beinginserted into a reader (e.g., the reader 230). Activating the device orcomponents thereof in response to such actions may avoid delays inperforming functions and other activities that could be caused by tryingto activate components while performance of these functions isinitiated.

As described elsewhere herein (e.g., with respect to the step 506),managing operation of a health device may include reducing thermaloutput of a mobile health device based on detected temperature. FIG. 11is a flow diagram 1100 illustrating reducing thermal output of a mobilehealth device based on detected temperature, according to embodiments ofthe system described herein. Other embodiments of reducing thermaloutput of a mobile health device based on detected temperature, forexample, variations of the processing illustrated by the flow diagram1100, are possible and are intended to fall within the scope of theinvention. The processing illustrated by the flow diagram 1100 may beimplemented using the power control logic 284 of the controller 280(e.g., the controller 208) in combination with the one or moretemperature sensors 228.

In a step 1102, health metric values may be detected, for example, asdescribed elsewhere herein. In a step 1104, in one or more regions ofthe health device, a respective temperature may be detected, forexample, using the one or more temperature sensors 228 (e.g.,thermometers, thermistors). In a step 1106, it may be determined whetherthe temperature is too high; i.e., whether the temperature has passed apredefined threshold. For example, the power control logic 284 may beconfigured to receive detected temperature values from the one or moretemperature sensors 228 and compare the temperature values to thresholdtemperatures stored in a memory on the health device 200. The thresholdtemperatures may have been provided by the health services application312 and may be updated from time to time, for example, if analysisreveals that one or more thresholds should be revised. Alternatively,the threshold temperatures may be maintained by the health servicesapplication, and retrieved therefrom for comparison by the power controllogic 284; or the detected temperatures may be communicated to thehealth services application to be compared to the thresholds, and theresults of the comparison communicated back to the power control logic284.

If it is determined in the step 1106 that the temperature is too high,then control transfers to a step 1108 where one or more action(s) may betaken or continued (i.e., if the one or more action(s) were previouslytaken already when a too-high temperature was previously detected) toreduce the temperature; e.g., to reduce the thermal output of the healthdevice or one or more components thereof. For example, in an embodimentin which the controller has multiple processing cores (e.g., CPU cores),one or more of the cores or CPUs thereof may be deactivated or not usedto execute instructions. In some embodiments, the step 1106 may includedecreasing a frequency of instruction execution of one or moreprocessing cores or individual CPUs.

In a step 1110, the detected health metric values may be adjusted toaccommodate that a temperature within one or more regions of the at thetime of detection may have affected the accuracy of the values detected.Such adjustments may be made based on rules and/or information (e.g.,stored within data structures on the controller 208 or within the healthservices db(s) 302), which may be based on empirical data from pastobservations.

In a step 1112, the health metric values may be processed, for example,as described in detail elsewhere herein, e.g., to be used to determineinterventions. After performance of the step 1112, control returns tothe step 1102, described above, to begin another iteration. It should beappreciated that performance of steps 1106, 1108 may include performingone or more actions during one iteration and one or more differentactions during later iterations. For example, after a processing core isdeactivated and/or an execution frequency of a core reduced during onepass, another processing core may be deactivated and another core'sfrequency reduced, or a core's execution frequency reduced further,during a later pass. Furthermore, the processing illustrated by the flowdiagram 1100 may include re-activating cores and increasing executionfrequencies of cores as temperatures decline.

As described elsewhere herein, an MLE may be applied to determine one ormore interventions as part of providing a health service. FIG. 12 is aflow diagram 1200 illustrating applying an MLE to determine one or moreinterventions as part of providing a health service, according toembodiments of the system described herein. Other embodiments ofapplying an MLE to determine one or more interventions as part ofproviding a health service, for example, variations of the processingillustrated by the flow diagram 1200, are possible and are intended tofall within the scope of the invention. The processing illustrated bythe flow diagram 1200 or portions thereof may be implemented using theMLE 326. Furthermore, it should be appreciated that one or more aspectsof the processing illustrated by the flow diagram 1200 may be performedusing a mechanism other than an MLE and techniques other than machinelearning, for example, by applying rules-based logic such as, forexample, the rules analysis logic 324.

In a step 1202, the MLE (e.g., the MLE 326) may be applied to arecipient health model (e.g., the health data model 304) and healthmetric values (e.g., the health metric values 340) to produce an actionlist (i.e., a list of intervention actions). In some embodiments, thehealth metric values have already been aggregated (and normalized asnecessary) into the recipient health model such that the health metricvalues are not separately input to the MLE.

In some embodiments, an action list produced by the step 1202 is aranked list; i.e., the step 1202 includes ranking the determinedactions, e.g., based on which action is deemed optimal for treatingwhatever condition is being serviced; i.e., for producing an optimalhealth outcome. For example, the MLE may have been previouslyinitialized and trained as described in more detail elsewhere herein,which may have involved using the health data model 304. The step 1202may include applying the MLE after the training to produce a list of oneor more actions. For each determined action, the MLE also may havecalculated a value (e.g., a weight or score) indicative of theeffectiveness of the action for the health condition being serviced, andthe one or more actions may be ranked according to an effectivenessvalue.

In some embodiments, the step 1202 may include determining a sequence oftwo or more actions; i.e., two or more actions to be performed in aspecific sequence. For example, the actions may include taking a firstmedicine before taking a second medicine. In such embodiments, thesequence of actions may be treated as a unit. For example, either allactions of the sequence performed in the order prescribed, or none ofthe actions are performed (e.g., are filtered out).

In a step 1204, safety rules may be applied to any remaining actions inthe action list, for example, as described in more details elsewhereherein. As noted above, employing machine learning to autonomously orsemi-autonomously determine interventions may be more dynamic andflexible than employing purely rules-based analysis, but the resultsalso may be more unpredictable than those from rules-based analysis.Accordingly, for safety reasons, it may be desirable to use safety rulesand/or a list of safe or unsafe actions to filter a list of actions. Insome embodiments, the filtering may be applied before the step 1202; forexample, to rule out the possibility of any potentially dangerousactions being produced from the step 1202.

Safety rules may include rules that require that certain conditions bemet to perform an action and/or that prohibit performance of an actionif certain conditions are met. For example, a rule might specify that ahealth communication of “Go exercise for at least 10 minutes” cannot beprescribed to a recipient if an average and/or most recently measuredblood glucose level is below 60. Another rule may specify that a healthcommunication instructing the user to take insulin cannot becommunicated unless the medical record pf the recipient indicate thatthe recipient is insulin-dependent. Any of a variety of other safetyrules may be defined and applied.

In a step 1208, timing for each remaining action in the action list maybe determined; and in a step 1210, a respective expiration for eachremaining action in the action list may be determined. For example, adetermined action may be that a patient is directed to take amedication, but only if the medication is taken between 8:00 pm and10:00 pm, an estimated time period approaching a bedtime of the patient.The action may have a timing of 8:00 pm and an expiration of 10:00.Thus, a health communication 346 may be sent at 8:00 pm, causing amessage instructing the patient to take the medication to be displayedon a screen of the health device until 10:00 pm, at which time themessage may stop being displayed.

In a step 1212, the best actions may be selected from any remainingactions in the action list. For example, as described elsewhere herein,the actions may be ranked based on a determined effectiveness of theactions (e.g., based on a determined effectiveness value). One or moretop ranked action may be selected. For example, it may be determinedthat, even though there are several remaining actions in the list, thenumber of actions or the required instructions or explanations to sendfor the quantity of actions it too much to perform and/or digest,respectively, such that the list should be pared down. In such a case,it may be determined that a certain number of actions should be removed(e.g., from bottom of the ranked list), and the remaining actionscommunicated to the recipient. For example, a rule may be applied orconfigured into MLE logic to limit the number of interventionscommunicated to a recipient per day (e.g., one, two or three per day)and/or to certain times of day (e.g., only one intervention communicatedbefore noon, and one communicated after 5:00 pm), perhaps withexceptions for urgent or emergency interventions.

As described elsewhere herein, determining an intervention may includedetermining a list of one or more actions to perform, and may include,as described with respect to the step 1204 of the flow diagram 1200,filtering the action list by applying safety rules to the list before orafter other filtering is applied to the list; that is, safety rules maybe applied to the remaining actions in a list of interventions. Applyingsafety rules to a list of intervention may include filtering the list ofinterventions against a list of safe actions.

FIG. 13 is a flow diagram 1300 illustrating filtering a list of one ormore determined actions against a list of safe actions, according toembodiments of the system described herein. Other embodiments offiltering a list of one or more determined actions against a list ofsafe actions, for example, variations of the processing illustrated bythe flow diagram 1300, are possible and are intended to fall within thescope of the invention.

In a step 1302, it may be determined whether there is a next (e.g.,first) action in the ranked list. If it is determined in the step 1302that there is not a next action in the ranked list (i.e., all actions inthe action list have been processed), then processing is complete.Otherwise, control transfers to a step 1304 where it is determinedwhether a next action is in a safe list. The safe list may have beenpreviously generated, e.g., manually by a practitioner, group ofpractitioners or organization, and may have been provided in an externalsource.

If it is determined in the act 1304 that the next action is in the safelist, then control transfers to a step 1306 where the next action iskept in the action list; otherwise, control transfers to a step 1308where the next action is removed. Following either the step 1306 or thestep 1308, control transfers back to the step 1302 for anotheriteration.

In some embodiments, in addition to, or as an alternative to, applying asafe list, the list of actions may be filtered against a list of unsafe(e.g., clinically unsafe) actions, which may involve applying similar(but converse) actions as described above with respect to a safe list ofactions.

As described elsewhere herein (e.g., in connection with the step 514 ofthe flow diagram 500), determining interventions may include detectingirregularities of health metric values and determining one or moreinterventions based on detecting irregularities. FIG. 14 is a flowdiagram 1400 illustrating detecting irregularities of health metricvalues, and taking action based on the detection, according toembodiments of the system described herein. Other embodiments ofdetecting irregularities of health metric values, and taking actionbased on the detection, for example, variations of the processingillustrated by the flow diagram 1400, are possible and are intended tofall within the scope of the invention. An irregularity may mean that:the person from whom health metric values were detected is not therecipient; one or more components of the health device are not workingproperly; and/or there has been a significant, perhaps dangerous, changein a health condition of the recipient.

In a step 1402, one or more first detected health metric values of arecipient may be detected. Such values may be detected during multipleperformances of the step 508 as part of performance of the processingillustrated by the flow diagram 500. From the first detected metricvalues, a baseline for the health metric values (e.g., blood pressure,blood glucose levels, heart rate, weight, body mass index (BMI),cholesterol levels, triglyceride levels, etc.) may be established. Thebaseline values may be recorded as part of the recipient data 303 and/orthe health data model 304.

In a step 1406, one or more second health metric values may be detected,for example, as part of a later performance of the step 508. In a step1408, it may be determined whether any of the one or more second healthmetric values constitute an irregularity, for example, as part ofperformance of the step 514 of the processing illustrated by the flowdiagram 500. For example, for one or more health metrics, the secondvalues of the health metrics may be compared to the respective baselinevalues for the health metrics. If a calculated difference (e.g., anabsolute or percentage difference) is above a certain threshold, it maybe determined to constitute an irregularity. A calculated differencebelow a threshold may be interpreted to not constitute an irregularity.For example, a weight loss threshold of 20% over a predetermined periodof time may be defined (e.g., in a rule) such that a loss of 20% or more(e.g., 40% body) of weight over the predetermined period of time may bedeemed an irregularity, whereas a loss of less than 20% (e.g., 5%) maynot be deemed an irregularity.

Determining an irregularity may involve considering factors other thanthe differences in health metric values, including, for example: thetime period over which the values were detected; a rate of change over atime period; and context and conditions during which the values weredetected (e.g., hot summer day; during or immediately after strenuousexercise or other activity; immediately following a meal; duringdaytime; while asleep). For example, a 40% increase in heartrate from abaseline heartrate may not be significant if detected immediatelyfollowing a kick-boxing session, but may be considered an irregularityif detected while the recipient has been at rest for a certain period oftime. These contextual values may be detected by a health device orentered into the health device by a recipient in connection with thehealth metric values being detected.

If it is determined in the step 1408 that there is an irregularity, thenone or more actions to take may be determined (e.g., as part ofperformance of the step 514), and in a step 1410 the one or more actionsmay be taken. The one or more actions may include communicating theirregularity to one or more entities including, for example, therecipient (e.g., on the health device or to another device and/orcontact for the recipient), the caregiver of the recipient; apractitioner; a healthcare organization; etc. Communicating theirregularity may alert the one or more entities to the possibilitiesthat: someone other than the recipient is using the health device; thehealth device (e.g., one or more sensors thereof) is not workingproperly; there has been a significant, potentially dangerous, change ina health condition of the recipient. The communications of theirregularity may take any of a variety of forms, including any of thecommunication and/or media types described herein. For example, a visualand/or audial alarm (e.g., a blinking light, repeating beep) may bedisplayed or played, respectively, on the health device; and/or a highpriority notification may be sent to a physician.

Various embodiments discussed herein may be combined with each other inappropriate combinations in connection with the system described herein.Additionally, in some instances, the order of steps in the flowcharts,flow diagrams and/or described flow processing may be modified, whereappropriate. Furthermore, various aspects of the system described hereinmay be implemented using software, firmware, hardware, a combination ofsoftware, firmware and/or hardware and/or other computer-implementedmodules or devices having the described features and performing thedescribed functions.

Software implementations of the system described herein may includeexecutable code that is stored on one or more computer readable mediaand executed by one or more processors. Each of the one or more computerreadable media may be non-transitory and include a computer hard drive,ROM, RAM, flash memory, portable computer storage media such as aCD-ROM, a DVD-ROM, a flash drive, an SD card and/or other drive with,for example, a universal serial bus (USB) interface, and/or any otherappropriate tangible or non-transitory computer readable medium orcomputer memory on which executable code may be stored and executed by aprocessor. The system described herein may be used in connection withany appropriate operating system.

As used herein, an element or operation recited in the singular andpreceded with the word “a” or “an” should be understood as not excludingplural elements or operations, unless such exclusion is explicitlyrecited. References to “one” embodiment or implementation of the presentdisclosure are not intended to be interpreted as excluding the existenceof additional embodiments that also incorporate the recited features.Furthermore, a description or recitation in the general form of “atleast one of [a], [b] or [c],” or equivalent thereof, should begenerally construed to include [a] alone, [b] alone, [c] alone, or anycombination of [a], [b] and [c]. In addition, use of a an ordinal term,e.g., “first,” “second” or the like, to qualify a term for an itemhaving multiple instances of the same name does not necessarilyindicated a priority, precedence or temporal order between the instancesunless otherwise indicated, but rather such ordinal terms may be usedmerely to distinguish between the separate instances.

Other embodiments of the system described herein will be apparent tothose skilled in the art from a consideration of the specification orpractice of the system disclosed herein. It is intended that thespecification and examples be considered as exemplary only, with thetrue scope and spirit of the invention being indicated by the followingclaims.

1.-40. (canceled)
 41. A method of deploying a mobile health device toprovide a health service for a person for a health condition, the methodcomprising: accessing a profile of the person; defining a value for afirst parameter of the mobile health device based on the profile;configuring the mobile health device based on the value of the firstparameter; and giving possession of the mobile health device to theperson.
 42. The method of claim 41, further comprising: after givingpossession of the mobile health device, receiving a first communicationfrom the mobile health device; in response to receiving the firstcommunication, sending a second communication to a second deviceassociated with the person; receiving a third communication; andauthenticating that an operator in possession of the mobile healthdevice is the person based on receipt of the third communication. 43.The method of claim 42, wherein the second communication includes anaccess code, wherein the third communication is from the mobile healthdevice and includes the access code, and wherein authenticating is basedon the third communication including the access code.
 44. The method ofclaim 42, wherein the third communication is from the second device, andwherein authenticating is based on the third communication beingreceived from the second device.
 45. The method of claim 41, furthercomprising: creating the profile for the person at a time of purchase ororder of the mobile health device.
 46. The method of claim 41, whereinthe profile includes a first parameter value specific to the person andassociated with a health condition of the person.
 47. The method ofclaim 46, wherein the mobile health device includes a health sensor formonitoring a value of a health metric of the person, and wherein thefirst parameter value is specific to the health sensor.
 48. A system fordeploying a mobile health device to provide a health service for aperson having a health condition, the system comprising: one or moreprocessors; and a memory having code stored thereon that, when executed,accesses a profile of the person, defines a value for a first parameterof the mobile health device based on the profile, and configures themobile health device based on the value of the first parameter.
 49. Thesystem of claim 48, wherein the code, when executed, receives a firstcommunication from the mobile health device after the person takespossession of the mobile health device, sends a second communication toa second device associated with the person in response to receiving thefirst communication, receives a third communication, and, based onreceipt of the third communication, authenticates that an operator inpossession of the mobile health device is the person.
 50. The system ofclaim 49, wherein the second communication includes an access code,wherein the third communication is from the mobile health device andincludes the access code, and wherein the authenticating is based on thethird communication including the access code.
 51. The system of claim49, wherein the third communication is from the second device, andwherein authenticating is based on the third communication beingreceived from the second device.
 52. The system of claim 48, wherein thecode, when executed, creates the profile for the person at a time ofpurchase or order of the mobile health device.
 53. The system of claim48, wherein the profile includes a first parameter value specific to theperson and associated with the health condition of the person.
 54. Thesystem of claim 53, wherein the mobile health device includes a healthsensor for monitoring a value of a health metric of the person, andwherein the first parameter value is specific to the health sensor. 55.Non-transitory computer-readable media having software stored thereonthat deploys a mobile health device to provide a health service for aperson with a health condition, the software comprising: executable codethat accesses a profile of the person; executable code that defines avalue for a first parameter of the mobile health device based on theprofile; and executable code that, prior to possession of the mobilehealth device being given to the person, configures the mobile healthdevice based on the value of the first parameter.
 56. The non-transitorycomputer-readable media of claim 55, the software further comprising:executable code that, after possession of the mobile health device hasbeen given to the person, receives a first communication from the mobilehealth device; executable code that, in response to receiving the firstcommunication, sends a second communication to a second deviceassociated with the person; executable code that receives a thirdcommunication; and executable code that authenticates that an operatorin possession of the mobile health device is the person based on receiptof the third communication.
 57. The non-transitory computer-readablemedia of claim 56, wherein the second communication includes an accesscode, the third communication is from the mobile health device andincludes the access code, and authenticating is based on the thirdcommunication including the access code.
 58. The non-transitorycomputer-readable media of claim 56, wherein the third communication isfrom the second device, and wherein the authenticating is based on thethird communication being received from the second device.
 59. Thenon-transitory computer-readable media of claim 55, the software furthercomprising: executable code that creates the profile for the person at atime of purchase or order of the mobile health device.
 60. Thenon-transitory computer-readable media of claim 55, wherein the mobilehealth device includes a health sensor for monitoring a value of ahealth metric of the person, and wherein the profile includes a firstparameter value specific to the health sensor. 61.-150. (canceled)